硕士学位论文
面向容器编排平台的自动化调优系统研究
作者姓名: 王新元
指导教师: 赵琛 研究员
中国科学院软件研究所
学位类别: 电子信息硕士
学科专业: 软件工程
培养单位: 中国科学院软件研究所
2024 6
Research on Automated Optimization System for Container
Orchestration Platform
A thesis submitted to
University of Chinese Academy of Sciences
in partial fulfillment of the requirement
for the degree of
Master of Electronic and Information Engineering
In Software Engineering
By Xinyuan Wang
Supervisor: Professor Chen Zhao
Institute of Software Chinese Academy of Sciences
June 2024
中国科学院大学
研究生学位论文原创性声明
本人的指
作所。承用的含任
个人或集体享有著作权的研究成果,未在以往任何学位申请中全部或部分提交。
对本的研他个中以
式标明或致谢。本人完全意识到本声明的法律结果由本人承担。
作者签名:
期:
中国科学院大学
学位论文使用授权声明
本人集、使
的规科学照学公开和保的原
保留并向国家指定或中国科学院指定机构送交学位论文的电子版和印刷版文件,
且电版内该论阅,
学位或部描、段以
法律许可的方式保存、汇编本学位论文。
涉密及延迟公开的学位论文在解密或延迟期后适用本声明。
作者签名: 导师签名:
期: 期:
I
基于和学广
原生通过器编排平,如 Kubernetes 等,进行应用程序的署和护,旨在
提高敏捷性,需求
环境。
但在维护中,的参及资
源调数配台忽数的
响,集群程序传统
案依验,以覆况和
多的资源平台和简
值判缩或广泛应架构
程序和服的可性、能和用性 SLOService Level Objective,服务水
平目标)指标,且难以处理微服务架构为代表的整体的复杂集群场景。
因此的优
的性降低集群题。
决上述问题,本研究工作内容包括:
1. 设计并实现一个面向容器编排平台的容器集群自动化调优系统。该系统
架构设计根据容器编排平台 Kubernetes 机制深度定制,由控制模块、调优模块、
参数块、模块块基
需求文件,协同工作,实现自动化调优。
2. 配置线-线括基
集成线辅助学习线法。
建负载知识库和参数知识库,能够在负载到达集群时,有效利用离线先验知识,
准确签并荐,置基
行快速的迭代优化。
3. 分配-
微服源分环境配置
行结合,在满足用户自定义的 SLO 前提下,为微服务系统提供基于实时工作负
载的参数更低性能
节省或消源,能力
发支持能力的目的。
使 Nginx Memcached Redis
PostgreSQL化系
面向容器编排平台的自动化调优系统研究
II
使 46.55% 208.20%
HotelReservation
P99 使
37.5%况下 3
以上。
关键词:云原生,容器编排平台,参数配置,资源分配,自动化调优系统
Abstract
III
Abstract
The cloud native software development and deployment paradigm has received
widespread attention from the industry and academia. Cloud native deploys and
maintains applications through container orchestration platforms such as Kubernetes,
aiming to improve the agility, reliability, and maintainability of applications, adapt to
dynamic business needs and technological environments. However, there are
unreasonable parameter configurations and resource scheduling allocations in the
management and maintenance of container orchestration platforms. In terms of
parameter configuration, the container orchestration platform ignores the significant
impact of application parameters in the cluster, and does not consider adjusting the
corresponding parameters of the application in the cluster management process.
Meanwhile, traditional solutions rely on manual experience, are prone to bias, and are
difficult to cover multiple types of load situations and increasingly diverse parameter
configurations. In terms of resource scheduling, container orchestration platforms
mainly decide to shrink or expand resources based on a single indicator and simple
threshold judgments, ignoring the Service Level Objective (SLO) indicator widely
used to ensure the reliability, performance, and availability of applications and
services based on cloud native architecture, and making it difficult to handle complex
cluster scenarios represented by microservice architecture as a whole.
Therefore, based on the container orchestration platform, how to improve the
performance of the entire cluster environment while reducing cost consumption
through resource and parameter optimization is a key issue in current cluster
performance optimization. To address the aforementioned issues, the scope of this
study includes:
1. Design and implement an automated optimization system for container
clusters based on a container orchestration platform. The system is deeply customized
based on the container orchestration platform Kubernetes mechanism, consisting of
four functional modules: control module, tuning module, parameter resource
management module, and observation module. Four modules work together to
achieve automated tuning.
2. A combination of offline and online recognition optimization methods has
been proposed for parameter configuration optimization, including offline auxiliary
training methods based on ensemble learning and online parameter tuning methods
based on machine learning. By constructing a load knowledge base and a parameter
knowledge base, it is possible to effectively utilize offline prior knowledge when the
load reaches the cluster, accurately identify and initialize parameters, and perform
rapid iterative optimization on the basis of optimal configuration.
3. For resource allocation optimization, a resource parameter joint optimization
Research on Automated Optimization System for ContainerOrchestration Platform
IV
method and a resource descent algorithm are proposed. The optimization of resource
allocation strategies in microservice systems is combined with the optimization of sub
application parameter configuration. Under the premise of meeting user defined SLO,
the optimal combination of real-time workload based resource allocation and
parameter settings is provided to maintain the original performance with lower
resource consumption, or to provide higher concurrency support with the same
resource consumption.
This study validated the effectiveness of the optimized system using four
different applications: Nginx, Memcached, Redis, and PostgreSQL. The results show
that the automated tuning system implemented in this study can improve the average
performance of the application by 46.55% to 208.20%. In addition, in the
microservice architecture HotelReservation scenario with actual workloads, this
optimization system can save more than 37.5% of resources while meeting the service
level goal of ensuring average latency and P99 latency to meet user usage needs, or
use the same resources to support user concurrency reaching more than three times the
default configuration.
Key Words: Cloud native, Container orchestration platform, Parameter configuration,
Resource allocation, Automatic optimization system
目录
V
1 绪论 ......................................................................................... 1
1.1 研究背景及意义 ................................................................................................. 1
1.2 相关工作与研究现状 ......................................................................................... 4
1.2.1 资源分配方法 .............................................................................................. 4
1.2.2 参数调优方法 .............................................................................................. 6
1.3 本文研究内容 ..................................................................................................... 8
1.4 论文组织结构 ..................................................................................................... 9
2
相关理论和技术基
............................................................11
2.1 虚拟化技术 ....................................................................................................... 11
2.1.1 虚拟化技术概述 ........................................................................................ 11
2.1.2 容器虚拟化技术 ........................................................................................ 12
2.1.3 Docker.........................................................................................................13
2.2 Kubernetes 技术概述........................................................................................ 15
2.2.1 Kubernetes 基本概念介绍......................................................................... 15
2.2.2 Kubernetes 基本架构介绍......................................................................... 17
2.3 微服务架构 ....................................................................................................... 19
2.4 本章小结 ........................................................................................................... 20
3 自动化调优系统设计实现 .................................................... 22
3.1
设计总览
........................................................................................................... 22
3.2
控制模块
........................................................................................................... 23
3.2.1
功能执行
.................................................................................................... 23
3.2.2
流程控制
.................................................................................................. 23
3.3
调优模块
........................................................................................................... 24
3.3.1
应用程序调优
............................................................................................ 25
3.3.2
微服务调优
................................................................................................ 25
3.4
参数资源管理模块
........................................................................................... 26
3.4.1
参数修改和资源修改的异同
.................................................................... 26
3.4.2
参数
-
资源模块的适配
............................................................................... 26
3.5
观测模块
........................................................................................................... 27
3.6
工作流程概览
................................................................................................... 27
3.7
本章小结
........................................................................................................... 28
面向容器编排平台的自动化调优系统研究
VI
4
离线
-
在线结合的识别优化方法
........................................... 29
4.1 离线辅助训练 ................................................................................................... 29
4.1.1 负载知识库 ................................................................................................ 29
4.1.2 参数知识库 ................................................................................................ 34
4.2 在线参数调优 ................................................................................................... 36
4.2.1 基于模型的调优 ........................................................................................ 37
4.2.2 无模型的调优 ............................................................................................ 41
4.2.3 优化目标设置 ............................................................................................ 42
4.3 本章小结 ........................................................................................................... 43
5 资源-参数联合调优方法及资源下降算 ............................44
5.1
微服务调优策略
............................................................................................... 44
5.2
基于进化算法的资源分配优化算法
............................................................... 45
5.3
资源下降的联合调优算法
............................................................................... 47
5.4
本章小结
........................................................................................................... 51
6 实验分析 ............................................................................... 52
6.1 实验环境 ........................................................................................................... 52
6.2 实验设计与评估 ............................................................................................... 52
6.2.1 应用程序调优 ............................................................................................ 53
6.2.2 微服务调优 ................................................................................................ 61
6.3 本章小结 ........................................................................................................... 66
7
总结与展望
............................................................................68
7.1 工作总结 ........................................................................................................... 68
7.2 未来工作展望 ................................................................................................... 69
参考文献...............................................................................................70
附录一 Task 示例 .................................................................................77
附录二
ControlAgent
示例
...................................................................78
.....................................................................................................80
作者简历及攻读学位期间发表的学术论文与其他相关学术成果..... 82
图表目录
VII
图目录
1
-
1 Tomcat
不同配置下的性能表现
.................................................1
1
-
2 Nginx
自动配置示
...................................................................2
1-3 论文组织结构............................................................................. 9
2-1
传统虚拟化和容器虚拟化架构对比
........................................ 12
2
-
2 Kubernetes
架构图
.................................................................... 17
2-3 HotelReservation 微服务架构................................................... 19
3-1 面向容器编排平台的自动化调优系统架构.............................21
3-2 自动化调优系统工作流程概况................................................ 27
4-1 负载识别流程图....................................................................... 30
4
-
2
递归采样的示例图
....................................................................41
5-1 面向 SLO 的微服务系统优化概况 ..........................................45
6
-
1 Nginx
实验评估结
.................................................................52
6-2 Nginx 迭代优化过程.................................................................52
6-3 Redis 实验评估结果................................................................. 53
6
-
4 Redis
迭代优化过
................................................................. 54
6
-
5 Memcached
实验评估结
....................................................... 54
6
-
6 Memcached
迭代优化过
....................................................... 55
6
-
7 PostgreSQL
实验评估结
....................................................... 56
6-8 PostgreSQL 迭代优化过程....................................................... 56
6-9
优化参数取值的归一化概
....................................................57
6-10 低并发度压力实验评估的优化过.......................................59
6-11 高并发度压力实验评估的优化过.......................................60
6-12
调优前延迟随并发程度增加的变化曲线
............................... 62
6-13 调优后延迟随并发程度增加的变化曲线............................... 62
面向容器编排平台的自动化调优系统研究
VIII
表目录
1-1 Kubernetes 默认资源调度策略...................................................3
3
-
1
自定义资源定义和控制器概述
................................................ 22
3
-
2
参数修改接口概述
....................................................................25
4
-
1 MongoDB
负载类型概
..........................................................28
6
-
1
实验环境一
............................................................................... 49
6-2 实验环境二............................................................................... 49
6-3 应用程序调优参数筛选情况....................................................50
6
-
4
应用程序调优测试相关配
....................................................51
6-5 Nginx 实验设置 ........................................................................ 51
6
-
6 Redis
Memcached
实验设置
................................................53
6-7 PostgreSQL 实验设置 ............................................................... 55
6-8 并发优化实验结果....................................................................61
6-9 本研究与 Cilantro 工作实验对比............................................ 63
绪论
1
1
绪论
本章统研
次介和参作和阐述
主要研究内容,最后介绍本文的总体组织结构。
1.1
研究背景及意义
KubernetesK8sYARNOmega
Mesos
[1][2][3]
自动化部展容的工
助用员能施,容器
确保够高在这定的
序的参数地会,这
种容器编排平台的使用当中。其中由云原生计算基金会CNCF
[4]
管理和支
Kubernetes
Red Hat 报告
[5]
,截至 2021 Kubernetes 载了 88% 的容器化工作负载,成
行业的事基准。因,本研究续的开将面向开源 Kubernetes 容器
平台,但研究的设计思路适用于上述各种容器编排平台。
如前并不
应用进行的优置不
或参较差使偏低实际 1-1
示,以 Web 应用服务器 Tomcat
[12]
为例,X 坐标轴是其参数 maxConnections
取值Y socketBuffer_Byte 值,Z 轴则是不同参数取值情
况下导航表现数取
佳表现和最差表现差距可达数十倍。
1-1 Tomcat 不同配置下的性能表现
Figure 1-1 Performance of Tomcat with different configurations
面向容器编排平台的自动化调优系统研究
2
50% 30%
关的
[6]
,这致的能问
遍存中各此,提高
资源统效。同机上
数配平台部署根据
[7]
器线资源中最线分配
实际在较物理经验
1-2 Nginx CPU
[8]
。但是在环境CPU 配,而导
动配置出现错误,使得系统整体性能下降。
1-2 Nginx 自动配置示例
Figure 1-2 Example of Nginx automatic configuration
Apache Hadoop
[9]
作为一个开源的大数据平台有大 400 参数,由于其巨大
处理,在广使Hive 是基 Hadoop
1200 便
Apache Spark
[10]
式方式存、管和处理大据,大约 180 个参需要调整以正的方
调整改善量和的调
程度人工间内完成
但是用程负载围值
性难以保证。此外,研究表明并非所有的参数都对这些应用的性能有重大影响,
只有数一会明能,Hadoop Hive 109
个参数会对性能产生影响Spark 则有 30 参数会对性能产生影响
[11]
。因此
识别部署化的是十
必要性的。
Kubernetes
绪论
3
制来理容资源Pod Kubernetes
CPU
使
Kubernetes
足够常运费和指定
Kubernetes 使
请求可以够的器不使
超过指定数量的资源,从而防止容器消耗过度,避免过分占用资源导致的浪费。
但这①容理分费和
能会整体②难限制
用程资源载的;③
细粒度的资源管理,仅能管理 CPU 和内存资源。
同时Kubernetes 两种资源理策略用控制 Pod 的资源使用量
别是 VPAVertical Pod Autoscaler HPAHorizontal Pod Autoscaler
[13]
VPA 使
Pod HPA 种水
根据 CPU 指标,自扩展或缩 Pod 但两种资源管
策略是,断进本数
扩展应用序,通过在容器中 CPU存等资,以高应程序的负
载能优的有正过度
不足,还、负康检 1-1
行详细介绍。
1-1 Kubernetes 默认资源调度策略
Table 1-1 Kubernetes default resource scheduling strategy
特点
技术
功能
调度
kube-scheduler
根据不同的策略将容器分配给工作节点。
准入控制
更改和验证控制
在发布对象之前,但在对请求进行身份验证和授
权之后,拦截对 Kubernetes API 服务器的请求,
这提高了集群的安全性。
负载均衡
轮训机制
在多个容器实例之间分配负载,复杂策略可以由
外部负载平衡提供。
健康检查
启动、活跃、准
备和关闭探测器
控制容器是否可以答复请求。
容错
副本控制器
指定并维护所需数量的容器。
面向容器编排平台的自动化调优系统研究
4
自动伸缩
水平自动缩放器
通过自动增加或减少 Pod 数量来重塑
Kubernetes 的工作负载,可使用自定义指标。
此外 SLOService Level Objective
[14][15]
导向
优化与用求相险。SLO 服务,用定义
服务性能一种队和
定服务的期望水平,并为评估服务提供商的表现提供依据。因此,感知 SLO
SLO 为优化导向,是极具实际意义的
[16]
综上台的
系统控制数资块,
个功能模块构成。能够基于实时工作负载,进行离线-线结合的识别和优化,
能够史经并动。此
系统同时支持资源和参数的联合优化,通过资-数联合调优方法及资源下降
算法,在满足用户自定义的 SLO 前提下,提供基于实时工作负载的资源分配和
参数设置的最佳组合。其优势在于:
1 离线训练和在线实时反馈相结合;
2 兼顾参数配置和资源分配;
3 面向用户实际需求,自动化调优。
本系服务
到提高性能表现、提高资源利用率、提高用户并发程度、满足 SLO 的目的。
1.2
相关工作与研究现状
基于资源
优化源分器编配的
量(CPU内存等)。参数配置优化指的是针对系统内核、容器运行时或应用程
序等的参数配置的调优。
1.2.1
资源分配方法
目前集群
数学分配法的于机
的资源分配方法这四个方向。
1.2.1.1 传统集群资源分配方法
传统集群资源分配调度算法主要有以下三种
[69]
1. Min-Min 算法的策略是将任务调度到各项性能最高的节点上,这样可能
会造成任务的过度集中,可能会调度时延较高或者节点崩溃的问题。
2. First-Fit 算法在调度任务时会尽可能将任务放到利用率较高的节点上,
绪论
5
这样会提高集群内的资源利用率也减小了碎片化的问题,但是可能会
造成任务时延上升,服务质量下降。
3. Most-Full 算法会将任务调度到节点资源最多的节点上,这样可能会造
成节点资源碎片过多的问题。
传统服务
问题,往往不能满足集群实际生产的需求。
1.2.1.2 基于数学建模的资源分配方法
线线ILPInteger Linear Programming
等数可以组受使准的
术来确定题的佳解决方。但 ILP 方法很高计算成本复杂,因
[17]
AdaptiveConfig
机制响因、可态)
规则务规作性关因
时将巨大配置空间的集群级搜索转换为等效的动态编程问题
[18]
1.2.1.3 基于启发式算法的资源分配方法
启发,找
找到在传广使用。策略
进先出,DRFDominant Resource Fairness
中,Beltre A
[19]
综合考虑 DRF 的使用,以及任务的资源需求和平均等待
时间公平。但法需
每个租户的主导份额
[20]
,随着租户数量的增加,调度开销变得非常显著。因此,
该算法的应用一般都有较低的复杂度,明显存在优化质量欠佳的问题。
此外的方
然界能过的两配的
对环境的适应,包括遗传算法GAGenetic Algorithm
[70]
蛙跳算法(FLA
Frog Leaping Algorithm
[71]
和粒子群法(PSOParticle Swarm Optimization
[50]
等等Lin M
[21]
建立基于器的服务调度多目优化提出
蚁群调度质量素更
Chandrasekaran K 等人
[73]
采用时分片抢占的思来解决 CPU 源在器间
分配不均问题。Yang Y
[74]
使用优先级策略来解决集群网络资源在多任务请
求下的竞争问题Herbein S 等人
[75]
也采用优先级思想来决了多容器下的
I/O 负载均衡的需求。但是,上述方法受限于启发式算法的局限性,不可避免
易出现过早收敛于非全局最优解的问题,同时,存在优化时间过长的缺点。
面向容器编排平台的自动化调优系统研究
6
1.2.1.4 基于机器学习的资源分配方法
机器,可
容做出智能调度决策。
Frim
[15]
使使 SLO
化学训练而对特定服务进行自动缩容Frim 值得
的是为了整个强化过程Frim 入错入机从而使得
Frim
奖励机制,所以 Frim 并不能多目标优化,其更新策略时需要对模型进行完全的
使 Frim 使
时,往往需要较大的代价进行重新训练。
Cliantro
[22]
提出的问题是希望在针对真实场景中在不需要预训练的情况下对
真实 SLO Cliantro 放弃使对整
个集群的负载进行识别,而是直接使用真实世界的端对端指标(平均延迟、P99
-Cilantro
基于策略略选微服
馈对整个微服务集群进行多目标调优。
Deeprest
[23]
则是使用深度学习算法基于微服务中 API 量的变化来预
不同CPUIO)等
服务率和测。个工
庞大行训整个析工
没有基于预测来进行资源或者参数推荐来优化性能。
Harmony
[24]
使
习。网络态映基于
置决励样测模使样本
练,对未的位决策算奖。类DL2
[25]
使用深度习驱的深
习集群的调度器,包括在线监督学习和通过强化学习的现场反馈。
1.2.2 参数调优方法
Kubernetes
部署的任化,或采
初始复杂务架单一
景中区别缺乏务的
优工本研分配优势
虑资源分配的同时,兼顾针对不同应用程序的参数优化。
目前例如
优化和面向系统内核的参数优化。这虽然与复杂集群场景的参数优化存在差异,
绪论
7
但这些工作在一定程度上可以给本研究提供一定的参考。
1.2.2.1 面向应用程序的参数优化
典型的应用程序例如数据库、分布式计算框架,都有许多参数优化工作。
BestConfig 使
发散采样(Divide and Diverge Sampling)和递归边界搜索(Recursive Bound and
Search
局部最优
[11]
CDBTune
[26][27]
QTune
[28]
使用了强化学习的方法来进行参数训练。
通过态到象成一个
来进数据个马最终
训练数。Ottertune
[29]
斯优出通
数据来做分类历史
据,在数据量较大时有助于帮助快速找到最优解。
计算框架,如 Apache Spark可以采用 SVM 立模型来预测
[30]
使 ANN
[31]
SVM
ANN 都是浅层的机器学习方法,当数据集有较多的噪声或复杂的高维度时,
Tunful
[76]
使
GPBMOO
[77]
则针对 Spark 执行过程中调整的内核和驱动程序内存的数量,基于
帕雷,实DAC
[88]
实现据大 Spark
配置使用负载数据
配置的函数,并利用遗传算法根据模型估计的执行时间搜索良好的配置Wang
[89]
Spark 16
36%,但这种方法需要大量的执行样本来构建准确的回归树模型。
1.2.2.2 面向系统内核的参数优化
华为的 A-Tune
[32]
是一款基 AI 开发的系统性能优化引擎,通过实时数据
采集练服技术准的
像,出业能决的系
配置组合,使务处最佳运状态TuxML
[33][34]
使用随机森林法基配置
项对编译出的系统内核进行错误检测和镜像大小预测TEAMS
[35]
提出一种新
转移型转系统外处
初始预测模型转移到其未来版本,对不同版本的 Linux 内核配置进行迁移学习,
并得到很好的效KernTune
[36]
采用支向量机(SVM的方对系统的
前负持续每当,系
确定新的系统类,并动态调整更新内核的运行时参数。
面向容器编排平台的自动化调优系统研究
8
1.3 本文研究内容
本文所部
为研对其配以下降
浪费用户析优挑战
设计容器化调参数
配两线-线-
调优方法及资源下降算法。
具体地,本文的研究内容展开如下:
1. 面向容器编排平台,遵循模块化分布式部署的技术路线,设计实现面向
集群的自动化调优系统。其主要包括四个模块:控制模块、调优模块、
参数资源管理模块、观测模块。控制模块控制管理整个调优系统的运行
逻辑,同时作为控制中心与其他三个模块进行交互。调优模块部署优化
算法,以有状态服务器的形式,接受性能或状态信息,并优化资源分配
和参数配置。参数资源管理模块提供可自定义的参数以及资源修改接口,
负责根据调优策略更改集群中容器状态。观测模块负责执行基准测试收
集性能指标,或根据需求监控状态指标。
2. 在应用程序参数配置优化方面,针对如何在负载到达集群时,有效利用
历史经验或专家知识库等先验知识,进行准确识别和初始化的参数推荐,
以避免初始化的不合理配置导致较差的性能表现,同时能够在较优的配
置基础上进行快速的迭代优化的挑战进行研究,提出了基于集成学习的
离线辅助训练方法和基于机器学习的在线的参数调优方法,前者使用基
于分类回归树的最佳深度的随机森林进行负载识别,并通过回归分析筛
选与性能相关度较高的参数,迭代完成负载知识库和参数知识库的构建,
后者包括:使用高斯过程回归作为代理模型的改进的贝叶斯优化算法或
基于随机搜索和网格搜索无模型的搜索算法的调优流程,同时提供多目
标优化的选项,兼顾用户自定义需求。
3. 在微面, SLO 下,
源和参数的优化,减少集群整体资源消耗,同时提高集群并发处理能力,
提出了资-数联合调优及资源下降算法。面向 SLO 进行资源总量的
调整,基于多层次优化的理念,结合变异算法完成对最佳资源分配的搜
索,在搜索结果基础上优化参数配置,探索更低的资源占用以及更高的
并发支持。
4. Nginx
[8]
Memcached
[37]
Redis
[38]
Postgresql
[39]
上验证优化系统的有效性。结果
表明,本系统能够在各种资源分配条件下为应用程序带来性能优化,尤
绪论
9
使
46.55% 208.20%
在满足服务水平目标(Service Level Objectives, SLO,即保证平均延迟
P99 使 37.5%
或使用相同资源支持用户并发数达到默认配置的 3 倍以上。
1.4 论文组织结构
本文共分为七章,图 1-3 描述了本文各章之间的关系。
1-3 文组织结构
Figure 1-3 Thesis Structure
具体每一章的详细内容安排如下:
第一及意
群资和应及研调优
调优,引和调绍本
面向容器编排平台的自动化调优系统研究
10
究的主要内容,最后给出本文的组织结构。
第二系统
术进行详细介绍。首先是虚拟化技术,对比传统虚拟化技术和容器虚拟化技术,
Kubernetes 技术绍,要是 Kubernetes 和系
行阐述;最后对微服务架构以及典型的微服务基准测试 DeathStarBench
[40]
第三设计
排平台的优化系统的结构和功能,其主要包括四个模块:控制模块、调优模块、
参数资源管理模块、观测模块。详细说明其工作流程和交互方式。
线-线线-线
优化分为习的线基于
习的线调优知识库的
后者包括基于模型和无模型的调优流程。
第五章,资-数联合调优方法及资源下降算法。首先介绍面对微服务
优区用调研究述资
部分的变异操作函数和进化算法,最后介绍资-数联合调优方法及资源下降
算法。
第六统的
序调线-线方法-
联合资源应用果表
研究资源默认使性能
生明其是,优调优
实验两种源优验。
果显可使的资相同
表演或更高的并发支持能力,优化效果显著。
第七进行
有工作和结果对未来工作提出展望。
相关理论和技术基础
11
2
相关理论和技术基础
本章自动
Kubernetes
上述相关技术进行详细阐述,为后续的设计与实现工作奠定基础。
2.1
虚拟化技术
虚拟操作
化的虚拟硬件实例
使得统或台物而彼
相互隔离,互不干扰
[41]
。在过去几年,虚拟化技术取得了重大突破,在云平台、
物联拟化用。独立
以使硬件提供全的
境。化技断提长的
这些使拟化、物领域
或缺的关键技术。
2.1.1 虚拟化技术概述
1964 IBM
CP/CMS 系统的项。该中的 CPControl Program,控制程)组
操作管理的多来演
CMSCambridge Monitor System
监控系统)组件进行控制
[40][41]
VMware Inc 公司推出了商用化 VMware 虚拟
平台,该平台专为 X86_32 系结构设计。这个虚拟平台可以在基 X86_32
构的计算机系统上运行多个虚拟机,实现硬件资源的有效利用和隔离。
VMware 虚拟化平台是基 Hypervisor 虚拟化技术。Hypervisor(虚拟
机监一种体,建和
Hypervisor
机上每个分计间是
Hypervisor
的稳运行使 Hypervisor实现
Hypervisor
管理程序模式和宿主机管理程序模式
[41][42][43]
传统拟化 Hypervisor 一台计算虚拟成多计算
机,共享破了升了
Hypervisor
面向容器编排平台的自动化调优系统研究
12
并与主机系统互隔。通 Hypervisor 实现虚拟环境能够
件资源进行隔离,确保各个虚拟机之间的独立性和安全性。
2.1.2 容器虚拟化技术
容器Container Hypervisor
然它拟化虚拟似,
2-1
Hypervisor
直接上运免了动程
外开器本化和器之
共享和内器的杂程
外,包含镜像往往
简,便应用同时模拟
启动作系缩短响应
著提
[42]
。然这种宿主统的式也:容虚拟
技术不能够实现虚拟机在 Windows 操作系统的主机上运行一个 Linux 容器的功
能。宿主个应提供
性和有限格安不同
统的场景。
2-1 统虚拟化和容器虚拟化架构对比
Figure 2-1 Comparison between traditional virtualization and container virtualization
NamespaceCgroups
Control Group,控制组)机制和 chrootChange Root,切根机制)实现。
1. NamespaceNamespace PID ID
IDIPC
相关理论和技术基础
13
。通使 Namespace 器可台宿
行,但彼此之间相互隔离,就好像它们在各自独立的系统上运行一样。
这种隔离性使得容器在共享宿主机资源的同时能够保持相对的独立性,
避免了相互之间的干扰,同时提高了安全性
[42]
2. Cgroups控制制是非强制性,用制、录和
进程使 Namespace
的功能,但只是从 Linux 内核的角度在进程间形成一种可视化的隔离,
而从底层物理资源的角度看,多进程依旧是共享完整宿主机物理资源。
主机
Linux /sys/fs/cgroup
各种 CPU 使用、内使 I/O 及网资源
使使的硬
的正。使 cgroup 可以一组起,
进程
系统
进行资源管理和调度
[44]
3. ChrootChange Root 机制使
访Chroot
根目录文件夹则会被目标进程认为是新系统根文件夹(/,为不同的容
器设根目使影响使 Chroot
环境访
Chroot 所指的目录及其目录。这隔离机制可提供一定
分进访
[42][45]
广 Docker
容器虚拟化,其一整套 Docker 容器管理相关的生态推动了云原生的发展。
2.1.3 Docker
Docker 的概念最早 2013 Python 发者大会上首次提出,其设计
现包括 Docker 守护进程、Docker 户端、Docker 镜像、Docker 器和 Docker
仓库部分Docker 作为户端-务器
[46]
,用通过 Docker 客户与后
Docker RESTful
Representational State Transfer,具有代表性的状态传输)API
[47]
Docker DaemonDocker 守护进程):守护进程作为 Docker 中的主体部分,
是长期驻留在宿主机后台的服务进程,负责管理 Docker 对象,如镜像、容器、
网络和数据卷。它接收来自 Docker 客户端的请求,并管理 Docker 对象的创建、
面向容器编排平台的自动化调优系统研究
14
Docker Docker Server Docker Engine
Docker Server
Handler 行。在 Docker 守护进程中,最小任务单位是 Job,每个任务都
以抽象为一个 Job,并由 Handler Docker Engine 中执行具体任务的打包。
Docker ClientDocker 客户端):是任何遵循 Docker API 的客户端泛称
[48]
Docker 的主用户 Docker 端向 Docker 进程
Docker
字与 Docker Docker Server 通信Docker Server
听通信端口,并将处理完成的结果信息返回给 Docker 客户端。
Docker ImagesDocker Docker
文件。镜立的包含
Docker ,镜作为容器,用创建行容。镜像可
分享复使使部署。一
用户会通 Dockerfile 将应件、络配操作
统等要的打包并由器进
[49]
。生镜像会通
Docker Push 命令上传至镜像仓库进行存储。镜像仓库分为私有和公有两种。
Docker ContainersDocker Docker
每个个独应用以被
停止、删除等操作。
Docker RegistryDocker Docker
共的如 Docker Hub,也可以是私有的。用户可以从仓库中拉取镜像到本地使用,
DockerHub
[50]
的公有像仓库,类似 Github,将开源容器镜像维起来,以供用进行
拉取使从镜容器需的
具链,因此容器之间会以隔离的方式进行运行。
Docker 作为轻量级容器虚拟化技术,与传统虚拟化技术相比具有众多优势:
1 动时间:Docker 操作系统进程,不依赖宿主机操作系
统,不需要像传统虚拟机那样启动整个操作系统,只需启动应用程序及其依赖,
这使得在几秒内启动多个容器成为可能。
2 快速部署和持续 CI/CD持续集/持续交付通过 Docker 的快
速部发人其依的镜
并在不同环境中轻松部署,确保开发、测试和生产环境的一致性。真正做
次构建,到处运行,简化了部署过程,方便应用的迭代、迁移和交付,为软件
开发和部署提供了巨大的便利性和效率。
相关理论和技术基础
15
3 高效的资源利用率: 传统虚拟化技术使用 Hypervisor 来虚拟化硬件,
每个要一像,这导
高的源消括内存和间。Docker 器共操作统的
因此以共冗余用程
依赖,这使得资源利用更加高效。
4 Docker 便DockerHub
为迄有镜开源团队
护,可高效便捷投入生产环境。
2.2 Kubernetes 技术概述
随着广术挑
包括部署协调高应
的敏捷性、可靠性和可维护性等
[51]
。为了适应动态变化的业务需求和技术环境,
容器相关广部署器编
KubernetesYARNOmegaMesosDocker Swarm 等。本文所涉及的系统
Kubernetes 为基础,具体介绍 Kubernetes 技术的相关概述。
2.2.1 Kubernetes 基本概念介绍
Kubernetes 最初是 Google 开发的一于管器化应用源项
其设计目标是解决 Google 部大规模容器集群的管理问题,后由云原生计算基
金会(Cloud Native Computing FoundationCNCF管理
[4]
,是一个基于 Docker
技术编排化的供了
容器可以便署、容器
程序,并通过自动化的方式实现负载均衡、服务发现和自动弹性伸缩等功能。
Kubernetes
可移植和扩展的特。整 Kubernetes 平台多个件集成,这种计极
地方便理工行二于集
署,Kubernetes 提供了简化的流程,管理员可以通过一键式部署方式(kubeadm
init)来快速部署集群,无需过多关注部署细节,从而降低了使用门槛和部署成
Kubernetes
通信需要通过数字证书进行身份验证,采用双向的 TLS 认证机制,即客户端和
服务供身止了访问
Kubernetes
组件态,系统复,
群的稳定和可靠性这些特性使 Kubernetes 成为一个大且安全的集
面向容器编排平台的自动化调优系统研究
16
理工具,为企业提供了高效、可靠的容器编排和管理解决方案。
Kubernetes
容器量和行资的资
CNCF 的大家庭中,Kubernetes 拥有庞大的生态系统,包括各种插件、工具和服
务,如 Helm(包管理工具)Prometheus(监控工具)Fluentd(日志收集工具)
等,可以帮助用户更好地使用和扩展 Kubernetes。正是因为 Kubernetes 的安全、
易用、高效等优势,越来越多的企业选择 Kubernetes 管理公司集群。
Kubernetes 常见的资源对象有 PodControllerDeployment 等)Service
JobLabel 外,本研及用 API 的自义资义机制。
API YAML Spec
理对象具体配置。具体地,如下描述了这类资源对象的管理和基础运作流程。
1. Pod Kubernetes 的基本控制和管理单元
[52]
,也是最小的调度单位
[53]
Pod 可以视为一组容器的抽象,其中包含一个或多个共享存储系统、网
络接口等资源的容器。Pod 为容器提供虚拟主机环境,使其能相互协作
完成任务Pod Spec 字段设置的存储卷Volume路径挂载宿主
宿主机
[54]
Pod
能部个节 Pod 中所在一
上,
Pod
[53]
Pod Kubernetes
Pod 为基础进行运转。
2. Deployment 来管,无状态
宿任意
迁移的目标资源对象。Deployment RCReplicationController)机
设置
Pod Pod 退Deployment Pod
进行 Pod使个
修改
升响应速度。
3. Service 是为一组同功能的 Pod 提供统一访问接口,将请求负
均衡的分发给各个 Pod
[55]
。面对多个后端程序的 Pod 为前端提供服务,
Pod Kubernetes
Pod 特有的 IP 地址也随之发生变化,前端无法正确访问后端 Pod IP
Service Selector Pod
相关理论和技术基础
17
起来,对外提供一个统一的访问 DNS 接口,这样即使 Pod 发生变化,
接口地址也不会跟随变化。
4. Job 会创建一个或多个 Pod 直至成功运行的 Pod 达到指定的数量为止。
当有一个 Pod 失效退出时,Job 会自动创建新的 Pod 来完成任务。
5. Label 是附着在 Kubernetes 资源对象上的键值对,旨在为资源对象提供
用户,以 Pod 一般
调度场景中指定特殊的标签值为调度器提供筛选标准。
6. Controller 核心,用的实
,并
ReplicaSetDeploymentStatefulSet
DaemonSet Pod
用户也可以编写自定义 Controller 满足特定的业务需求,例如自
缩放、自动恢复等。
7. CRDCustom Resource Definition)是 Kubernetes 用于扩 API 的机
自定
资源一样 Kubernetes API 器处。用可以使用 CRD 来定义自
己的 API 资源,并编写对应的 Controller 来对这些资源进行管理和控制。
通过 CRD用户定义类型数据消息
实例等,然后编写 Controller 来实现这些资源的自动化管理。
2.2.2 Kubernetes 基本架构介绍
Kubernetes 分布式云计算集构采主从模式由若 Master 节点
Worker
[56][57]
2-2 Kubernetes
Master 点作集群理节点,运多个务端组件;Worker 节点实际工作
Master Worker
Master Worker
具体有以下几个核心组件。
面向容器编排平台的自动化调优系统研究
18
2-2 Kubernetes 架构图
Figure 2-2 Kubernetes architecture diagram
1. Master 节点上的核心组件:
1ETCDKey-
Value)数据库, etcUNIX 系统的 etc 配置目录)和 distributed(分布式)
命名ETCD 大的值存
于存储关键数据,如配置信息、元数据等。多个 ETCD 服务器通过 Raft
[58]
共识
算法点作 leader leader 广日志式一
致性问题,整集群状态信,如 PodService 配置信息,会以键
的形式存储在多个 ETCD 持久化存储卷中,提供对节点故障的容错机制
[59]
2API ServerAPI 服务器)API Server Kubernetes 集群的核心组件,
担任中的,作 Kubernetes 端,为集提供
各类资源对象的接口服务。所有的集群操作都通过 API Server 进行,包括创建、
更新、删除资源对象等操作API Server 过通信接口与 Worker 组件传递信
息,是整个系统的数据总线和数据中心
[53][57]
3Controller Manager
责集群中 Node(节点 PodNamespace(命名空间)和资源的管理,其通过
API Server
同时制器对象义的
行调节。例如,Replication Controller 负责管理 Pod 的副本数量。
4Scheduler Kubernetes
Pod 资源
Pod 分配中的 Node 节点调度大体和优走的
[54]
,预粒度,找合条的节预设法对
合条件的进行分,最终创建 Pod 与选 Node 的绑
[53]
。一
Kubernetes 对象 YAML
相关理论和技术基础
19
定调度器。
2. Worker 节点上的核心组件:
1Kubelet:是集群在每一个工作节点上的代理,主要负责创建、部署
和管理 Pod,具体地,通过接收 Pod 的创建、更新、删除等指令,确保 Pod
容器的运态符预期Kubelet Master 上的 API Server
册本点,点加入到,并 API Server 节点运行
及从 API Server 中接收新的节点状态并进行修改。
2Kube-Proxy是工作节点上的网络代理组件,负责维护节点上的网
Kube-Proxy Service 访
IP 服务发送到正确的后端程 Pod Kubernetes 络的核心组件。它维护
节点上的网络规则,使得服务可以被集群内外的其他组件访问。
3Container Runtime
Container Runtime DockercontainerdCRI-O 。它负责拉取镜像、创
容器、管理容器的生命周期等操作。
通常情况下,用户会通过 Kubectl 命令工具发起创建 Pod 请求,API Server
会首先收到请求并请求 YAML 的创建信息写 ETCD
后,将确息返至客户端Controller Manager 会持续监 API Server 的监
控接了任资源资源
ETCD Scheduler API Server
可调度的 Pod 信息,通过预设的调度算法将 Pod 与选中的节点进行绑定,并
ETCD Pod Kubelet Pod
创建;Kubelet 开始创建 Pod 资源对象,依次调 CNI 接口为 Pod 创建网络
CRI 口启 Pod 的容器、CSI 口为 Pod 创建挂载卷。至此 Pod 创建成
[60]
2.3 微服务架构
近年来,微服务作为一种新的应用开发模式引起了人们的广泛关注,并在
许多场合被采用。基于微服务架构,应用程序被设计为一组独立的、细粒度的
模块化服务,每个模块化服务执行单个业务任务,微服务之间使用轻量级通信
机制。应用程序的需求是通过一组协作的微服务来实现的。微服务应用程序易
于部署和更新,允许在不重新启动的情况下独立更新和重新部署某些服务,并
具有易于连续交付的特点
[61]
具体地,微服务将分布式应用程序分解为小型独立可部署的服务,每个服
务在自己的过程中运行,并通过轻量级机制进行通信。这些服务是围绕独立的
业务功能构建的,可以使用不同的编程语言和不同的数据存储技术编写。它们
面向容器编排平台的自动化调优系统研究
20
通常由完全自动化的部署和协调机制支持,例如在云中,使每个服务能够经常
以任意的时间表部署,只需最低限度的集中管理,通常遵循行业验证的
DevOps 实践
[87]
对微服务应用程序的设计、开发和评估需要可重复的实证研究,微服务架
构基准测试使得研究者能够对这种新的架构风格进行可重复的实证研究。其中,
DeathStarBench
[40]
,是由社交网络、媒体服务和酒店预订等微服务应用程序组成
的云微服务的开源基准测试套件。社交网络实现了一种具有单向关注关系的广
播式社交网络,用户可以通过该网络发布、阅读社交媒体帖子并对其做出反应。
媒体服务提供诸如审查、评级、租赁和流媒体电影等功能。酒店预订是一个在
线酒店预订网站,用于浏览酒店信息和进行预订。这些基准使用各种编程语言,
包括 JavaPythonNode.jsGoC/C++ScalaPHP Ruby,且所有微服
务都部署在单独的 Docker 容器中。
DeathStarBench 旨在帮助研究人员和工程师评估在大规模分布式系统中部
署新技术或优化现有技术时的性能表现。通过使用 DeathStarBench,用户可以
模拟和评估在大规模环境下各种常见的工作负载,从而更好地了解其在云基础
设施中的表现。这可以帮助他们进行系统设计、优化和决策,以提高系统的性
能、可靠性和效率。
2-3 HotelReservation 微服务架构
Figure 2-3 HotelReservation microservice architecture
如图 2-3 所示,酒店预订微服务(HotelReservation)实现了酒店预订服务,
使用 Go gRPC 构建。最初的项目以多种方式扩展,包括添加后端内存和持
久数据库,添加用于获取酒店推荐的推荐系统,以及添加预订酒店的功能。其
中,Nginx 作为前端入口负责请求的路由和负载均衡;Memcached 用作缓存层
提高系统性能;而 MongoDB 作为后端数据库主要承担数据存储和管理的任务。
2.4 本章小结
本章主要是针对本文系统开发所涉及的相关技术进行详细介绍。首先是虚
拟化技术,对比传统虚拟化技术和容器虚拟化技术,介绍较为流行的轻量级容
相关理论和技术基础
21
器虚拟化技术;其次是对典型容器编排平台 Kubernetes 技术的相关介绍,主要
是对 Kubernetes 中的基本概念和系统架构进行阐述;最后对微服务架构以及典
型的微服务基准测试 DeathStarBench 进行概述。
面向容器编排平台的自动化调优系统研究
22
3
自动化调优系统设计实现
3.1 设计总览
本研群参
自动。其线练和线,对
中部用程行参的自
优,以达到节省资源、提高资源利用率、满足 SLO 的目的。
基于排平
3-1 所示,其主要包括四个模块:控制模块、调优模块、参数资源管理模块、
测模控制优系作为
心与其他三个模块进行交互。调优模块部署优化算法,以有状态服务器的形式,
接受信息参数模块
自定及资据调器状
测模基准或根。本
部分,将对四个模块进行详细的介绍。
3-1 向容器编排平台的自动化调优系统架构
Figure 3-1 Architecture of Automated Optimization System for Container
Orchestration Platform
本系统有以下几点优势:
1. 拔式合适
的优化算法,实现负载识别、参数调优、微服务调优等多种功能;
2. 具有度拓:资-块设计为库模因而可以
面向
优,以及通用应用软件的性能调优;
3. 根据 Kubernetes 机制深度定制:设计基于 Kubernetes 控制器模式开发,
便对多
配;
自动化调优系统设计实现
23
4. 确保容器指标高效观测:通过自定义资源定义(CRD为每一次性
观测或指标收集生成一个独立对象,确保数据一致性;
3.2 控制模块
控制时作
个模。主群中、创
任务流程的调出的
数和署。包括线线选择
目标、参等等责控
系统务的其功和流
两部分。
3.2.1 功能执行
控制模块负责执行调优的迭代过程、多个任务的并行处理以及流程中错误、
超时同时的协载的
态,服务修改资源、参数后的状态,以及调优模块和其他模块之间的通信等等。
3.2.2 流程控制
控制模块基于自定义资源定义(Custom Resource DefinitionCRD)和控
器(Controller,将整个调优流程的控制抽象为不同类型 CRD 的维护和管理过
Controller CRD
createupdatepatchdelete 等行为并在现事件的变之后,做相应
操作,其本质逻辑是维护资源当前状态和资源定义状态的一致性。
控制模块具体包括 5 CRD 3 Controller,如表 3-1 所示。
3-1 自定义资源定义和控制器概
Table 3-1 Overview of Custom Resource Definitions and Controllers
CRD 名称
对应的 Controller
概述
task
taskcontroller
控制整个调优流程的资
源,与调优模块交互,
用户通过定义 task 来进
行一次调优任务
controlagent
用于保存修改参数的名
称以及修改方式,被
controlstepcontroller 读取
面向容器编排平台的自动化调优系统研究
24
controlstep
controlstepcontroller
基于选择的 controlagent
的信息完成参数的修改
collectagent
用于保存生成基准测试
或读取观测信息的方
式,被
collectstepcontroller 读取
collectstep
collectstepcontroller
基于选择的 collectagent
信息完成基准测试或读
取观测信息
控制 3-1 线的管
任务(task)并发执行的,针对每个需要执行的调优任务,具体的执行流程为:
1. 执行任务文件task.yaml,创 task ,由 taskcontroller 维护
taskcontroller control/collectagent
control/collectstep control/collectstep
的状态。
2. controlstep 获取当前状态的参数取值,collectstep 等待应用程序执行一段
时间,并获取观测数据;
3. 调优模块推荐下一轮的参数取值,controlstep 执行应用程序的更新;
4. 等待服务执行;
5. collectstep 获取当前参数在运行时的观测数据;
6. 返回步骤 3
3.3 调优模块
调优模块作为一个独立的算法服务部署在集群当中,主要功能包括:
1. 及离线
置信
观测据,线负载识库的应-签及模型离线
数知识库记录的应用-负载标签及其对应的优化配置等。
2. Remote
Procedure Calls方式互。要包调优
讯内
务:
自动化调优系统设计实现
25
task id(任务序列号)和任务当中 step id(步骤序列号)进行校验,
保证配置推荐和性能反馈的正确匹配。
3. ,单
务场调优现两不同化策分别离线-线结合的
优化方法和资源-参数联合调优方法及资源下降算法。
3.3.1 应用程序调优
针对种使线
助和在线参数调优。
离线的离线
同种用,压力载,
数调优的尝试,构建参数调优的先验规则。具体包括:
1)负载知识库:记录应用-负载标签及识别模型;
2)参数知识库:记录应用-负载标签及其对应的优化配置。
当有根据
境特征推荐初始参数调优范围,该范围便是待搜索的配置参数空间。
在线行,
行参荐的相应应用
参数优化。结合离线辅助训练,可以更快速获取优化的参数配置。
3.3.2 微服务调优
现实使以微
结合应用处面联合
配和参数调优,即:
1. 如何保证在每次资源分配的迭代时其参数是较优的,而非可能存在不合
理默认项的默认配置;
2. 如何在保证达 SLO 使用最少资的资源分配以及较
参数取值。
1将资
标,例如用户定义的 SLO 或一些性能指标,包括吞吐率、平均延迟等,来进行
迭代在资调优将应
参数作为沿用先来巨
算代应用的搜的,使
优化次数线优化的;
面,混合最优同的
配下数并下资中扮
面向容器编排平台的自动化调优系统研究
26
色是合调的组配中
的。
2工作
[22]
工作所使用的资源情况进行了如
类:
1. ,并
制,通过指定资源的扩缩容以满足 SLO
2. 工作
集群中进行资源的重新分配以满足 SLO
可以类型
算法中,并没有解决如何在满足 SLO 的同时,寻找最节省资源的资源参数策略,
这也是面临的挑战之一,同时是潜在的思路。
为应对上述挑战,在微服务场景, 本研究提供了一个参数-调优
方法及资源下降算法, 用于解决微服务场景中参数资源混合调优问题,以及在微
服务场景中如何选择最少的资源总量满足 SLO 以达到节省资源的目的。
3.4 参数资源管理模块
参数-资源管理模块进行参数以及资源的扩缩容以及参数的修改,提供了可
以自以及根据如需
不同及不改方改的
在调优过程中,控制模块发送算法模块推荐的参数资源,由参-资源模块进行
对应的修改,随后进行下一轮数据的收集。
3.4.1 参数修改和资源修改的异同
与单着各
存在相同方式差异
这一问题,参-资源管理模块被设计成了一个插件系统,提供了不同参数类型
(运文件改接同应
件文件,调用修改接口,从而达到对各类应用程序参数修改的支持。
3.4.2 参数-资源模块的适配
在具体对每个应用程序进行适配时,本研究基于 Kubernetes pod 口开
发了参数 3-2 分别 pod 的配
件、、环改的点在
在不修改用户本身容器镜像内容的情况下,直接进行参数修改。
3-2 参数修改接口概述
Table 3-2 Overview of Parameter Modification Interface
自动化调优系统设计实现
27
名称
功能
ConfigFilePupdater
修改应用配置文件中的配置
CLIParaPupdater
修改应用启动时命令行参数
RuntimeCLIPupdater
修改应用运行时配置
EnvPupdater
修改环境变量
3.5 观测模块
观测模块收集的指标主要包括两种,分别是:性能指标和状态指标。
1.
task.yaml
,由
指标
或使用相应的 collectagent,执行 collectstep 收集性能指标。
2.
cAdvisor
[78]
进行收集,其部署为 kubelet 组件中的守护进程,负责收集、
些信
使映资使
完整历史状况。具体包括:
1 CPU 使 CPU 使
间的 CPU 时间、过去一段时间的 CPU 负载平均值等。
2 内存使用度量:容的总内存使用量、器的工作集大、内
存缓存的大小、内存页交换的数量等。
3 网络 I/O 度量:包括发送和接收的字节数、数据包的数量等。
4 I/O
数、容器的总读取次数、容器的总写入次数等。
5 磁盘使用度量:包容器使用的文件系的总字节数、器可
用的文件系统的总字节数等。
这部分息会导出时序数据库使用时由 collectagent 据负
从数
终返回给控制模块。
3.6 工作流程概览
如图 3-2 所示于用
模块通过执行任务配置文件(task.yaml,创建 Task 资源,启动整个调优流程。
面向容器编排平台的自动化调优系统研究
28
Task 线线体由 Task
Task control collect
controlstep collectstep
controlstep collectstep 的状态。
controlstep
体情况参考参数资源管理模块介绍。collectstep 待应用程序执行一段时间,
获取观测数据,具体情况参考观测模块介绍;
整个控制 gRPC 式,
交互,具介绍内容
据具体任务需求,持续创建 controlstep collectstep,每次操作对应一个 step
终点配置文件task.yaml目标
阈值。
3-2 自动化调优系统工作流程概
Figure 3-2 Overview of workflow for Automated Optimization System
3.7
本章小结
本章台的
四个控制数资块,
设计思路、功能逻辑以及工作流程。
离线-在线结合的识别优化方法
29
4
离线
-
在线结合的识别优化方法
本章介绍离线-线结合的识别优化方法,主要分为基于集成学习的离线
助训于机线调优知识
建和的构型和实现
到达效利识库确识
始化,以配置,同
在较础上,使加符
任务负载,实现高性能表现。
4.1
离线辅助训练
3.3.1 所述,离线辅助训练指的是:本系统在脱离生产环境的离线阶段,
预先类的应用求分
载,优的的先具体
载知识库、参数知识库。
1. 载进
地,
进行
到达集群时,能够快速识别负载类型。
2. 后,
化应
一待
性能指标值最优时对应的参数配置。
4.1.1
负载知识库
应用时,
验或等先别和以避
化的导致时能上进
的迭代优化。
具体,识
及具体负载类别。
4.1.1.1
负载知识概述
本研用程
请求程度钟请求往
应用著的增加分布
面向容器编排平台的自动化调优系统研究
30
YCSBYahoo! Cloud
Serving Benchmark
[62]
MongoDB 型为种典
型:
4-1 MongoDB 负载类型概述
Table 4-1 Overview of MongoDB load types
标签
类型
workloada
读写均衡型
workloadb
读多写少型
workloadc
只读型
workloadd
读最近写入
记录型
workloade
扫描小区间
workloadf
读写入记录
均衡型
应用种分
学习类函该函映射
类别中的某一个,从而可用于数据预测。
训练是一
组成,而一个本形

1
,

2
,
,

;



签,对应不同类型或压力程度的负载。
Google
状态的可化工 cAdvisor
[78]
,其能收集聚集处理并导运行容器
CPU 使CPU 使使
数、磁盘写入字节、磁 I/O 等。这些息能够包级别的资
源隔源的使资源使完整
况,这些信息在不同负载之间存在差异。
利用的时过数负载
标签所属,即负载
其工作流程如图 4-1 所示。
离线-在线结合的识别优化方法
31
4-1 负载识别流程图
Figure 4-1 Flowchart for load identification
4.1.1.2 负载知识库的构建
实现状态
型负取样分类学习
得分类模型。本研究 CART 决策树Classification and Regression Tree
[79]
随机础分的方现负
库的构建。
1. CART 决策树算法
广
[80]
CART Leo
Breiman 等人 1984 提出,是一种通用的决策树生成算法。对于分类问题
CART 使用基数(Gini Index划分则,够获小基指数
的属性作为划分属性。
1 基尼系数

(
)
不确割后
性。基尼指数数值越大,样本集合的不确定性越大。
分类问题中,假设有个类,样本点属于第类的概率为
,则概率分布的
基尼指数定义为:

=
=1
1
= 1
=1
2
根据某个特征的某个取值
,将样本分为两个子集
1
,
2
,则数据集
对于特征的基尼系数为:
面向容器编排平台的自动化调优系统研究
32

,
=
1

1
+
2

2
=
1
1
=1
1
1
2
+
2
1
=1
2
2
2
2 特征处理
CART 是基型,对的分类
分类问题,因此需要对连续值和离散值作不同的特征处理。
1 连续值处:连续特征的理方采用离散。数的特
1
,
2
,
3
,
,
1
1
,
2
,
3
,
,

1
=
+
+1
2
的样本划分到集合
,大于
的样本划分到集合
+
计算
其作为二元离散值时的基尼系数。
2 离散:枚所有合,尼系
小的剩余接下裂中。例
1
,
2
,
3
情况:
1
2
,
3
1
,
2
3
1
,
3
2
。计算
1
2
,
3
2
3
中继续参与计算。
2. 随机森林算法
随机森林是一种集成学习方法,它通过构建并结合多个决策树来进行预测。
随机思想均的的预
CART
Classification and Regression Tree
节包括:
1 自助抽样
针对容器
载标进行生成集。
集的原始同。与原
数据同可本的够有
持数据特征的完整性和多样性,为模型训练提供稳定可靠的数据基础。
2 通过交叉验证设置决策树的最佳深度
离线-在线结合的识别优化方法
33
随机森林中 CART 决策树的深度,也就是树中最长路径的长度,对模型的
性能重要深度于复
可能训练但在上表
差。的深过于据中
模式和关系,这可能导致模型在训练数据和新数据上的表现都不好。
通过类决

_

[4, 7, 10]
。遍的深,创 CART 树分例,
最大使用Cross-Validation
[81]
性能
本研究具综合效果和成本选择
5
 验证将收到的
状态指标数据分成 5 份,模型会被训练 5 次,每次都用 4 份数据进行训练,剩
下的 1 份数据进行验证。
完成所有的深度取值的评估,则返回最佳的最大深度取值和对应的准确率,
基于此构建随机森林。
3 基于 CART 决策树和随机森林的负载识别算法
负载进行
略推造成重影所以
据一内的据的均的
果。cAdvisor 采样 1 在识 5
分钟时间内,共有 180 快照,对 180 数据进行处理和识别。其中,对于
container_cpu_load_average_10s 10 CPU
container_network_receive_packets_total
进行在此和异根据
的数过随终选类别
为输出。
综上所述,基于 CART 决策树和随机森林的负载识别算法如 4-1 所示。
算法 4-1 基于 CART 决策树和随机森林的负载识别算法
1. Input:历史数据集合_,对应负载标签_,预处理后的
待识别的状态属性集合
_
,森林中树的数量
_
,自助
抽样选项

,测量分割质量的函数

,树的最大深度集合
_
,剪枝的复杂性参数
_
,交叉处理次数

2. Output:识别出的负载类别标签
3.
4. // 定义字典类型的变量,包含
_
的候选取值,此处为[4, 7, 10]
5.  = {'_
'
: _}
面向容器编排平台的自动化调优系统研究
34
6.
7. // 基于 YAML 配置文件中调优算法相关字段,初始化随机森林模型
8.  = (
9.
_ = . ("_", 4), 树的数量
10.
 = . ("", ), 自助抽样
11.
 = . ("", ""), 基尼系数
12. _ = . ("_", 0.0005), 剪枝处理)
13.
14. // 交叉验证
_
最佳取值,此处 5,表示使用 5 折交叉验
15.
 =
(, ,  = )
16.
. (_, _)
17. _  =
. __
18.
19. // 识别分类
20.
  _  _
do
21. // 逐一分类
22.
 _ . (_)  
23.
 
24.
25. // 获取最匹配的类别标签
26.  = (). _(1)
27.  = [0][0]
28.
29.  
4.1.2
参数知识库
4.1.2.1
参数筛选
基本可以
地纳围内参数究选使
Least absolute shrinkage and selection operator
LASSO
[63]
来进行线性回分析从而计出哪些参对性的影响大。
保证更改基于范围
微调追求数修现变
终根据回归系数排序,选择一批主要参数进行调优过程。具体步骤包括:
1. 的自
一个,每 个参
矩阵规模为
离线-在线结合的识别优化方法
35
2. 。同
1
与自变量的行数保持一致。
3. 对参数和性能结果进行标准化处理,以确保它们具有相同的尺度。
4. 利用 LASSO 模型合数据,使带有 L1 正则化的损失函,该损
则化
而正
的复杂度。本研究中,设置正则化系数

= 0.1
5. 对值
的系
为正相关关系,绝对值为负的系数表示参数与性能表现为负相关关系。
6. 保留
要特征。
4.1.2.2 参数知识库的构建
基于开源 NginxApachePostgreSQLRedis
等,参数析,使用
使 ApacheBench
[64]
Sysbench
[65]
Pgbench
[66]
等基准测试工具,配置不同类型或者压力程度,使用下一节所描述
搜索性能为了本研
同的应用程序的参数修改范围做了相应的选择,以保证整个服务的正确性。
在资,本
容和部的致的的一
行学习和搜索,但考虑到微服务调优中的多层次资源-数联合调优,此处将资
源分配作为负载标签,仅探索不同参数的配置情况。
在符合规定 SLO 的情况下,即在当前配置满足目标性能要求的情况下,以
不同来模使通过配来
的覆能范便化过源配
下的最佳性能表现,具体过程如算法 4-2 所示。
算法 4-2 基于 LASSO 算法和参数调优的参数知识库构建算法
1. Input:默认性能表现
_
,性能数据集合
_
对应参数列表,对应参数配置_,正则化系
,求解器迭代次数_,优化停止阈值,参数重要
性筛选阈值
2. Output:参数推荐知识库字典

3.
4. // 对数据进行标准化处理,以确保其具有相同的尺度
面向容器编排平台的自动化调优系统研究
36
5.  = ()
6. _  = . _(_)
7. _  = . _(_)
8. //

值)
9. 
_

=

(

= 0.1,

_

=
2000,

= 0.0001)
10. 
.

(

_

_

,

_

_

)
11. 
=

.

(

.

_)
12.
13. // 创建参数名称和重要性的映射,并根据重要性对参数进行排序和筛选
14.
_ = {}
// 初始化排序后的参数重要性字典
15.
  ,   ,  
16.   >   //
只添加那些值大于阈值的键值对
17.
_  = 
18.  
19.
 
20.
21. 
_

_

=

(

_

)
22. 
= {}
// 初始化参数知识库字典
23. 
[

] =

_

24.

[

] =

_

25. 
[

_

] =

_

_

26.

[

_

] =

_

_

27.
28.   
29. 
_

=

()
30. 
_

=

()
31.
 
_

>

[

]
32.

[

] =

_

33.     
34. 
[

_

][

] =

_

[

]
35.  
36.
 
37.
 
38.
39.  
4.2
在线参数调优
3.3.1 线
用运行参,本法接
实现参数线训练化的
离线-在线结合的识别优化方法
37
置。
4.2.1 基于模型的调优
基于一个
来代表现是参用或
性能使已生的性习模
测配性能的关地,研究使斯过回归
[83]
的贝
优化
[84]
,除叶斯算法性、适应和不定性
棒性持、研究,进
高了调优下限并加快收敛速度。
4.2.1.1 模块构成
1)初始化策略:始化策略是指在开始优化过程之前,选择初始参数组合
的策数组化过要影
Low-discrepancy sequence
[82]
列生于生的随样方
避免算法免算致无
全局机采速探在建
中帮化算数的指导
索,个优叶斯如果
数组合距离全局最优解较远,可能需要更多的迭代轮次才能收敛。
使 Halton Sobol
Hammersley 序列和拉超立方抽样等。下是基于低差异序列采样的配置生成
的一般步骤:
a. 确定:首值范
据类型,包括浮点数、整数或离散数据等。
b. 选择合适求和
选择适合的低差异序列生成算法。
c. 对每:根参数
射和将其例如可以
射到[0, 1]的范围。
d. 使用低差生成
系列采样点。每个采样点表示一个配置。如果采样的参数配置与历史记录重复,
则舍弃掉本轮选择,重新随机选择本轮参数配置取值。
e. 反映点反围,
最终的配置。
面向容器编排平台的自动化调优系统研究
38
另一线训练
参数验信的调序列
法或采样较少并没
到较本研线中,线练的
识。达集运行类别
识别应负配置初始
中。应用加到证优
中,各个参数存在较合理的不劣于默认配置的选项。在迭代次数较少的情况下,
提高了调优下限,使得初始参数组合的选择更加合理,更符合调优实际。
2)代理模型:代理模型通过建立一个近似函数来代替目标函数(性能评
估函数),使用已生成的配置样本和对应的性能数据,训练机器学习模型来预测
配置与性能之间的关系。通过拟合已有的目标函数观测值,提供一个近似模型,
避免样和数带训练
型能够快速预测不同参数配置组合下的目标函数值,从而加速优化过程。
具体高斯
模型目标通过数和
数值来进型可方差
提供对预测结果的不确定性估计。
3)采样函数:根据已训练的模型,在参数空间中采样一组候选配置。这
些配较高接下步评
优化择下下一合。
说,在未在有在已
估计行进到最对目
的不,可采样根据
型的定性样本选择
高价进行样点指导
使本研究的在线参数调优算法更加高效地探索参数空间。具体包括:
a. 概率提升(Probability of Improvement:概率提升采样函数计算每个超参
数组过当它根布,
标函的概概率概率
数更特定那些平的
题。计算公式如下:

(
) =

(
)
(
)

(
) =
(

(
)

(
)
),

(
) > 0

(
)
(
)
离线-在线结合的识别优化方法
39
0

(
)
表示当前配置提升量,
(
)
表示配应的后验期标准差
(
)
表示累积分布函数。
b. Expected Improvement
预测的不数选的超
合作评估索未于选
有望带来更大改进的超参数。计算公式如下:

(
) =

(
)
(

(
)

(
)
) +

(
)
(

(
)

(
)
),

(
) > 0

(
)

(
)
期标准差。
(
)
表示累积分布函数,
(
)
概率密度函数。
c. Lower Confidence Bound
预测考虑确定概念
优化进行选择参数
为下的点好结并同
目标函数的不确定性。计算公式如下:

(
) =
(
)

(
2
)

(
)
其中
(
)
表示配置
对应的后验期望值,

(
)
表示配置
对应的后验期标
准差,表示调节系数,表示优化目标数,表示已经评估的观测总量。
d.Expected Improvement per SecondEIps
化问,用时间的程EIps 来评
候选。它:期是时
模型的后验期望值。计算公式如下:

(
) =

(
)
(
)
其中
(
)
表示配置对应的后验时间期望。
e.升(Probability Improvement per SecondPIps)是
化问,用概率了两
因素:概率改进和时间。计算公式如下:

(
) =

(
)
(
)
其中
(
)
表示配置
对应的后验时间期望。
面向容器编排平台的自动化调优系统研究
40
f.期望提升Constrained Expected ImprovementCEI用于
约束衡量合了,用
候选解在满足约束的前提下的优化潜力。在约束优化问题中,除了优化目标外,
还存在一些约束条件需要满足。候选解必须在约束条件下具有良好的性能。CEI
通过同时考虑目标函数的期望改进和约束条件的满足程度来评估候选解的优劣。
计算公式如下:

(
) =

(
)
=1
(
(
)

(
)
)
其中
(
)
表示配
对应的验期值,

(
)
表示配
对应的验期
准差,
(
)
表示累积分布函数。
4.2.1.2 调优流程
基于模型的调优的具体流程如下:
1)确定优化目标:即针对某一个优化目标进行优化,在应用程序调优中,
SLO,以及实际资源总量。
2)参数空间的构建:算法的参数空间基于应用配置文件,获取可修改的
参数默认础上数和
参数的参数空间。每次的新采样,将作为优化过程的参数推荐。
3)建立代理模型:本研究使用高斯过程回归作为代理模型来进行参数的
在线过程供了法来
探索间,线型较这对线
化十分重要。
4)选择优化起点:随机采样一定数量的初始点,构建贝叶斯优化器是最
简单。考使可能采用
序列采样。
5)循环优化过程:在每次迭代中,执行以下步骤:
a) 使用代理模型和样策略,在已知的参数配置中找一些有可能取
得更好结果的点行评估,同时试图发掘搜索空中尚未探索的区
域,选择下一个参数配置选项组合进行评估;
b) 根据上一步选择配置选项组合,更新整个应用序,随后继续等
待观测下一轮性能指标;
c) 记录性能指标,动态调整探索(Exploration)和开发(Exploitation
策略,并将其用于更新代理模型;
d) 根据代理模型的测,选择下一个配置选项组。终会在性能较优
的参数配置组合附近进行更密集的搜索,以寻找更加精细的最优解,
离线-在线结合的识别优化方法
41
直到找到可接受的最优解或者达到预设的时间上限。
具体地,如算法 4-3 所示。
算法 4-3 基于高斯过程回归的贝叶斯优化的参数迭代调优算法
1. Input:参数配置信息
_
,先验配置
_
,初始化采样配置数量
_
,采样函数

,初始化采样策略

,代理模型

,调优最
大迭代次数_
2. Output:推荐参数配置组合_
3. // 基于参数配置信息生成参数配置空间
4.  =
(_)
5. // 基于 YAML 配置文件中调优算法相关字段,初始化贝叶斯调优器
6.  = (_ = , //
数配置空间
7. _ = _// 先验配置
8.
__ = _
// 初始化采样配置数量
9.
_ = _
// 初始化采样策略
10.
_ = 
// 代理模型
11. _ = ) // 采样函数
12. // 迭代调优
13.
    _ 
14. // 计算新的推荐参数配置组合
15.
_ =
. ()
16. // 基于推荐参数运行基准测试,并计算评价指标
17.  =
(_)
18. // 更新调优器历史数据
19.
. (( =
_,  =
))
20.  
21.
22. // 获取最佳性能的参数配置组合
23.  . (). ()
4.2.2 无模型的调优
无模索最
面向容器编排平台的自动化调优系统研究
42
理模型。简单、直接,适用于小规模的超参数优化问题,计算开销较低。
具体的调优流程如下:
1. 确定优化应用
SLO,以及实际资源总量。
2. 参数空间,获
数列认配上,和连
数的参数空间。每次的新采样,将作为优化过程的参数推荐。
3. 使用随机样。使
尽可,采每次小距
多次中,最小,作
修改的样本,进行基准测试实验。
4. 在初始样周围
最近坐标,采取找
个具的点机搜先选
散的采样方式。
5. 如果找到围的
行采行以样本性能
达到设定的迭代次数或时间。
4-2 归采样的示例图
Figure 4-2 Example diagram of recursive sampling
4.2.3 优化目标设置
本研使反馈
是唯一的值,例如 Sysbench
[65]
等可以反馈数据库应用的吞吐率和延迟,最简
的方中某。但目标
略接接纳优化同的
标之间进行优化策略的选择。
离线-在线结合的识别优化方法
43
如果重要
线

=1
(
)
其中各个权值的关系为,
{

> 0,
= 1,2

,
=1
= 1}
或者,用户提出个优化目标值
0
= (
1
0
,
2
0
, . . . ,
0
)
,使得个目
函数逼近算出的差
(
(
),
0
) =
(
)
0
2
=
=1
(
(
)
0
)
2
,
++
学习数类,便单目
问题。
若没一个
取值在更新过这样
调优过程里,同时改善对于之前调优的评价。
4.3 本章小结
本章主要介绍离线-线结合的识别优化方法,本方法能够做到基于历史经
验或构建,有供初
荐,结合在线调优流程,高效快速完成参数配置的优化。
面向容器编排平台的自动化调优系统研究
44
5
资源
-
参数联合调优方法及资源下降算法
本研化在
造成,故中,调优
①尽可能用户义的 SLO;②第一个条,尽的节省用
源;基于此,本研究提出资-参数联合调优方法及资源下降算法,结合进化算
法,在满足用户 SLO 的前提下,兼顾资源和参数的优化,探索更低的资源占用
和更持,耗,理能
体地面对一应及本
调优策略,其次阐述资源分配部分的变异操作函数和进化算法,最后介绍资-
参数联合调优方法及资源下降算法。
5.1
微服务调优策略
本研究通过以下思路来解决 3.3.2 中提到的两个挑战:
1数是
在不合理默认项的默认配置。
核心使空间
快速的策题,化的
通过先分配资源随后进行参数调优的方式,来加速整个调优过程。
本研下,
数量为主导的,故在进行资源-参数推荐时,本研究先选定对应的资源分配空间,
随后优。对资选择
候选方案调优这样
效避统资程序索过
频繁变动造成的复杂优化状态。
挑战 2何在达到 SLO 后,找到使最少资源分配以及
优的参数取值。
核心问题是如何在已经满 SLO 的情况下,寻找一个可能存在的更加节省
资源的参数-资源分配策略。为了解决这一问题,本研究提出了一种资源下降策
SLO 源量逐渐而找 SLO
总量使用较少的方案。
值得注意的是, 资源可能存在的情况分为两类:
1. 初始化的资源分配能够满足 SLO
2. 初始化的资源分配不能满足 SLO
针对情况 1,本研究则可以通过资源下降算法,搜索满足 SLO 的情况下
资源-参数联合调优方法及资源下降算法
45
源使用较少的策略;针对情况 2,本研究则需要对其进行参数+资源优化从而使
其达到 SLO,同时保留更进一步优化的可能。
5.2 基于进化算法的资源分配优化算法
Evolutionary Algorithm
[85]
法,物进异和优解
究基,用。在将微
统中用程配一节点
目标最优使个叶源,
资源浪费量最小。具体步骤如下:
1. 生成初始的资源分配策略:
根据本研究景中,微服务内的子应用序数目(单元数)初始
使
分配情况,以便进化算法可以在此基础上逐步迭代改进。
2. 定义三种默认的突变操作函数:
略进
点的资源,或微调每个叶子节点的资源数量。具体而言:
a) 1
到目标节点。
b) 2
配资源量过低,导致整个微服务系统崩溃。
c) 3
线
保持一致。
略的
情况
寻找更好的解。
3. 计算历史策略相对得分:
面向容器编排平台的自动化调优系统研究
46
根据历史记录中的每个资源分配策略,获取微服务系统 SLO
而才历史记录中选择过去的最佳分配策略。
而是使
便
大小,计算每个策略被选中的概率。
=
1
,
2
,
,
=1
=
=
1
,
2
,
,




=
1

,
2

,
,

,其任意

=

/

。再

使用指数数进转换得到
=
1
,
2
,
,
,将

=
1
,
2
,
,
,其中
=
/

4. 生成新的评估点以用于下一轮迭代:
并将
中。
具体地,如算法 5-1 所示。
算法 5-1 基于进化算法的资源分配优化算法
1. Input:微服务的子应用程序数(单元数)_,资源总量
_,每个单元的最小分配资
___,每次变异操作选中的样本数s
2. Output:变异后的推荐样本
_
3.
4. // 基于微服务架构和资源总量生成初始的资源分配策略
5. __(_, _, ___)
6.
7. // 定义三种不同类型的变异操作的随机选择函数
8.
 __
9.  = [0.33, 0.67,1.0]
10.
 = . . ()
11.
  < [0]
12.  1
13.

14.   < [1]
15.
 2
资源-参数联合调优方法及资源下降算法
47
16.

17.  3
18.
 
19.
20.
// 迭代改善资源分配
21.   
22.
// 使用指数函数进行转换,以便更突出高得分策略的概率
23. _ =
____(, )
24.   _  _ 
25.  = __
26.
_ = (_)
27.
28.
 _
5.3
资源下降的联合调优算法
-
SLO(如吞吐率)大于

为例,展开算法概述。当整体性能指标为 P99 延迟
等优化目标为减小的指标时,SLO 即为小于

-数分
=
,
=
1
,
2

,
=
=1
=
1
,
2
化的分配记为
0
=
0
,
0
,其中,
0
0
为默认的完全公平资源分配
默认的参数配置。用 来表示某一个资源-参数分配观测到的指标,则有:
+
=
(
,
) =
(
+
)
1
1)式中,下标为对应的迭代次数,表示此时资源的分配已经进行了
迭代,参数优化进行了
次迭代。
如前所述,对于任意固定的资源总量,通过资源分配优化得到的最佳结果,
必然配置在资过参
得到,又优化本研
所有的性能指标相对于资源、参数的值在一个范围内,则可以大致画出图像。
面向容器编排平台的自动化调优系统研究
48
5-1 面向 SLO 微服务系统优化概况
Figure 5-1 Overview of microservice system optimization for SLO
线 1 优的线
研究范围线 2 为通源分性能
线;线 3 曲线 2 础上数调最优线
图中所示,取一个相较于 SLO 的参数待调整范围
,以及资源待调整范围
>
。随后,本研究对两种可能出现的情况分别展开讨论:
1
初始化的资源分配满足了 SLO
2
初始化的资源分配不能满足 SLO
首先针对情况 1, 本研究给出如下策略:在情况 1 中,默认的资源-参数分配
的情况下,取最大资源总量 ,存在:

<
0
=
(
0
)
2
体的,需
,且
步骤一,首先以
的的粒度对当前的资源进行收缩,得到收缩后的资源数
'
,直到当前的性能指标满足(图中点 A
0
'
<

3
步骤,随
的粒进行
''
状态使得
''
满足
(图中点 B

>
0
>

4
,随,
资源-参数联合调优方法及资源下降算法
49
源分配,即寻找一个
''
,使得:

>
(
) =
(
,
0
) >

5
超过

,则退回步骤一。若在设定的迭代时间和轮次内无法找到,则退
回步骤二。
步骤式中
0
表示依旧. 此时其参
进行优化,得到性能最优的参数组合
,此时性能为:
+
=
(
+
) =
(
,
)
6
步骤五,此时得到了当前
''
上最优的性
+
,取一个最小迭代粒
,此时分为以下情况:
1.
+
''
<

时,
> 时,使
=
''
=
''
+
''
到步骤三;
2.
+
''
>

+
使
=
''
=
''
<= 0
时,停止,视为达到优化极限。否则,回到步骤三;
3.

<
+
''
<

+
为迭
参数组合以及最节省资源的分配方式。
具体地,资源下降的联合调优算法如算法 5-2 所示。
算法 5-2 资源下降的联合调优算法
1. Input:服务水平目标 SLO 取值

,资源优化潜在范围
,参数优
化潜在范围
,性能上限阈值
当前分配资源量 R,每次收缩的资源数
,每次微调的资源数
,资源调优最大迭代次数

_

,参
数调优最大迭代次数
_

2. Output:优化后的性能_和资源占用
3.
4.   
5.  _ >


6.
=
7.  _ <


8. = +
面向容器编排平台的自动化调优系统研究
50
9.
1:
10. _ = 0
11.
 _ <


12.
_
13. _ += 1
14.
 _ = _
15. _ = 0
16.  1
17.  
18. 2:
19.
_ = 0
20.
 _ <


21.
_
22.
_ += 1
23.  _ = _
24.
_ = 0
25.
= 1
26. = +
27.  2
28.  
29.  _ >

+
30.
_ = 0
31.
= 1
32. =
33.
 2
34. 
35. 
36.  
37.
38.  _
针对情况 2,本研究给出如下策略:
时, SLO则整体的更新
变为前资总量-数组先进配的
调整;
步骤二,当最的资源分能够满足
0
>

时,则去判断
其是否有进一步节省资源的机会;
步骤三,当最优的资源分配不能满足
0
>

时,即可以认
为此时的资源分配到了情况 1 中的步骤四情况,故本研究针对情况 2 的解
资源-参数联合调优方法及资源下降算法
51
决方法时直接进入联合调优算法的步骤四部分,开始参数调优。
5.4 本章小结
本章主要介绍资-数联合调优方法及资源下降算法,阐述其如何应对微
服务调优区别于单一应用调优的两个挑战,从而在满足用户 SLO 的前提下,兼
顾资优化用和少集
资源消耗,同时提高集群并发处理能力。
面向容器编排平台的自动化调优系统研究
52
6
实验分析
本章介绍向容排平台动化优系基于 Kubernetes 这一
排平台,在单一应用和微服务架构上进行调优任务的实验评估,包括实验环境、
实验。实分别优和
评估线-线方法-资源
降算。其的实,分
源优化实验和并发优化实验。
6.1 实验环境
96 96GB
Ubuntu 22.04 openEuler 22.03Kubernetes v1.23.1
境如表 6-1 6-2 所示。
6-1 验环境一
Table 6-1 Experimental Environment 1
CPU
Intel(R) Xeon(R) Platinum 8153 CPU @ 2.00GHz *
3
内存容量
8 * 16GB DIMM VMW-16384MB
硬盘容量
512 GB
操作系统
openEuler 22.03 LTS
Kubernetes
v1.23.1
6-2 验环境二
Table 6-2 Experimental Environment 2
CPU
Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz *
6
内存容量
8 * 16GB DIMM VMW-16384MB
硬盘容量
512GB
操作系统
Ubuntu 22.04 LTS
Kubernetes
v1.23.1
6.2
实验设计与评估
本研究的具体实验评估分为两部分:
实验分析
53
1. 应用程序调优实验评估:
基于离线辅助训练的负载知识库和参数知识库,针对基准测试中的
观测指标,使用基于模型或无模型的优化策略,对应用程序进行参数调
优,获取不同的性能表现;其次使用不同的资源范围,探索不同参数在
相应资源配给情况下的最佳取值,验证优化中容器编排平台所部署的应
用程序的参数配置的可行性和必要性。
2. 微服务场景调优实验评估:
微服务场景中,对资源和应用参数进行协同调优,并且以整体的端
到端在调尽力 SLO 时的
资源优化,根据请求并发度的不同,测试较低并发(资源充足)和较高
并发(资源不充裕)两种情况。两种情况下,本研究都试图在最少资源
消耗的情况下,调整微服务环境,使得整个系统尽可能满足 SLO
在上评估 SLO 时所
支持的最大压力,更进一步的探索。证明本优化系统能够在面临不同负
载压力情况时,能够以满足 SLO 为首要目标,同时兼顾减少资源消耗、
支持更高并发两个目标。
6.2.1 应用程序调优
6.2.1.1 实验概述
为了用程
线辅助训练和在线参数调优策略在优化应用参数方面的有效性。在优化实验中,
本研个微用的序, NginxMemcachedRedis
Postgresql DockerHub
[50]
和稳并使些应,本
据离线的结择与数,
验规则,进行调优实验。具体参数选择情况如表所示。
6-3 应用程序调优参数筛选情况
Table 6-3 Filtering of application tuning parameters
应用
版本号
回归分析筛选后的参数数量
Nginx
1.25.3
14
Redis
7.2.3
13
Memcached
3.18
21
PostgreSQL
16.1
15
面向容器编排平台的自动化调优系统研究
54
与此下的
有不的应进行索优
应用程序的性能情况。具体资源配给和基准测试情况如表 6-4 所示。
6-4 应用程序调优测试相关配置
Table 6-4 Configurations for application tuning testing
应用
基准测试
资源配置
Nginx
ApacheBench
[64]
1-8 CPU
Redis
Memtier_benchmark
[86]
1-8 CPU
Memcached
Memtier_benchmark
[86]
1-8 CPU
PostgreSQL
SysbenchTPC-C
[65]
1-8 CPU
6.2.1.2
实验结果
1Nginx 实验结果
本实验使用超文本传输协议(HTTP)性能测试工具 ApacheBench,该工具
设计意图是描绘当前服务器的执行性能,显示服务器每秒可以处理的请求数。
实验中 ApacheBench 的设置如表 6-5 所示。
6-5 Nginx 实验设
Table 6-5 The setup of Nginx experiment
参数
概述
设置值
-cconcurrency Number of
multiple requests to make
一次产生的请求个数(并发数)
400
-nrequests Number of
requests to perform
测试会话执行的请求个数(测试总
共要访问页面的次数)
100000
worker_processes Nginx
worker_connectionsmulti_accept
(启用该选项可以使工作进程尽快接受新连接)keepalive_timeoutKeep-Alive
连接的超时时间)等参数。
6-1 CPU
以看,不配给的情优化统均善性尤其 8CPU
吞吐率提升 46.55%(每秒处理请求数由 86315.70 提升至 126499.00
实验分析
55
6-1 Nginx 实验评估结果
Figure 6-1 Evaluation results of Nginx experiment
8CPU 6-2
标为。可次的自动
系统逐渐为 Nginx 推荐出更佳的参数。
6-2 Nginx 迭代优化过程
Figure 6-2 The iterative optimization process of Nginx
2Redis 实验结果
本实验使用 Redis Labs 推出的一款命令行工具 Memtier_benchmark,该工
具能够产生各种各样的流量模式,根据需求生成多种结构的数据对数据库进行
压力测试,帮助了解目标数据库的性能极限。实验中 Memtier_benchmark 的设
置如表 6-6 所示。
面向容器编排平台的自动化调优系统研究
56
6-6 Redis Memcached 实验设
Table 6-6 The setup of Redis and Memcached experiment
参数
概述
设置值
-n--requests
指定每个客户端发送的请求总数
10000
-t--threads
设置线程的数量
24
-c--clients
设置并发客户端的数量
40
--radio
设置读写操作的比例
10:1
--key-minimum
设置键的最小大小
100000
--key-maximum
设置键的最大大小
300000
--data-size
设置每个请求的数据大小(以字节
为单位)
1024
maxmemorymaxmemory-policy
maxmemory maxclients
的最大数量)appendonly(是每次作后将数据追磁盘件中tcp-
backlog(设置 TCP 连接队列的长度)等参数。
6-3 CPU
以看,不配给的情优化统均善性尤其 8CPU
吞吐率提升 208.20%(每秒处理请求数由 116832.64 提升至 360083.44
6-3 Redis 验评估结果
Figure 6-3 Evaluation results of Redis experiment
8CPU 6-4
标为。可次的自动
系统逐渐为 Redis 推荐出更佳的参数。
实验分析
57
6-4 Redis 代优化过程
Figure 6-4 The iterative optimization process of Redis
3Memcached 实验结果
本实验使用 Redis Labs 推出的一款命令行工具 Memtier_benchmark,该工
具能够产生各种各样的流量模式,根据需求生成多种结构的数据对数据库进行
压力测试,帮助了解目标数据库的性能极限。实验中 Memtier_benchmark 的设
置与 Redis 实验相同(如表 6-6 所示)
优化实验覆盖 memory-limit(设置 Memcached 实例可以使用的内存限制)
lock-memory 使 slab-growth-factor
Memcached chunk 小增长因子slab-min-size(指 key+value+flags
小空间)threads(使用线程数量)等参数。
6-5 CPU
以看,不配给的情优化统均善性尤其 8CPU
吞吐率提升 51.01%(每秒处理请求数由 313686.69 提升至 473707.74
6-5 Memcached 验评估结
面向容器编排平台的自动化调优系统研究
58
Figure 6-5 Evaluation results of Memcached experiment
8CPU 6-6
标为。可次的自动
系统逐渐为 Memcached 推荐出更佳的参数。
6-6 Memcached 代优化过
Figure 6-6 The iterative optimization process of Memcached
4PostgreSQL 实验结果
本实验使用基于 LuaJIT 的可脚本多线程基准测试工具 Sysbench,该工具
最常用于数据库基准测试,但也可用于创建不涉及数据库服务器的任意复杂工
作负载。实验中 Sysbench 的设置如表 6-7 所示。
6-7 PostgreSQL 验设置
Table 6-7 The setup of PostgreSQL experiment
参数
概述
设置值
-
测试脚本
oltp_read_write.lua
--threads
工作线程总数
32
--tables
指定用于测试的表的数
300
--table-size
指定用于测试的表的大
小(行数)
100000
优化实验覆盖 shared_buffers
maintenance_work_mem VACUUMINDEX
使 wal_buffers
random_page_cost
effective_io_concurrency IO work_mem
实验分析
59
(每个查询运行时可以使用的内存量)max_wal_sizeWrite-Ahead Log 日志文
件的最大大小)等参数。
6-7 CPU
以看出,不同资源配给的情况下,本优化系统均可改善性能,尤其在 8CPU 时,
吞吐率提升 49.76%(每秒处理请求数由 2048.99 提升至 3068.54
6-7 PostgreSQL 实验评估结果
Figure 6-7 Evaluation results of PostgreSQL experiment
8CPU 6-6
标为。可次的自动
系统逐渐为 PostgreSQL 推荐出更佳的参数。
6-8 PostgreSQL 迭代优化过程
Figure 6-8 The iterative optimization process of PostgreSQL
面向容器编排平台的自动化调优系统研究
60
综合分析:
可以序往
能表源发和优的差
生明其是,默数设
46.55%
208.20%
在此置情
不同参数的最佳取值情况。对比结果如图 6-9 所示:
6-9 优化参数取值的归一化概况
Figure 6-9 Overview of normalization of optimization parameter values
图中,各
CPU
性能时该参数取值

与默认配置

的取值进行归一化处理之后的值,

=

/

。通过归一化处理,使得各个参数的优化取值
与默认值的数量关系保持在同一数量级,方便对比以及规律的观察。
可以一定
数的够依区间成一
上的,更的最,考
同类况,样未便动化线
实验分析
61
优的必要性。
6.2.2 微服务调优
DeathStarBench
[40]
HotelReservation使用 wrk2
[67]
和提负载验,优化
有效观测使到端服务
延迟,判断其是否能够满足根据用户需求设置的 SLO作为优化的首要目标
在第五英特尔至强可扩展处理器的性能报告
[68]
中,针 DeathStarBench
测试使用 P99 延迟 100ms SLO其处
吞吐变化实验沿用定, P99 100ms SLO
况下,进一步关注资源消耗以及微服务所能支持的负载并发程度。本次实验中,
CPU
客户请求的事务数。
6.2.2.1 实验概述
72 CPU HotelReservation 19
应用进行分配,默认情况下 72 CPU 以公平策略分配给每个应用。CPU 资源
在微的分算法,根
分配情况进行突变操作得到的分配策略。
CPU 源总调整是基源下联合法,定每
路为 SLO
逐步耗,扩张后的
9 2 CPU
被设置为较大值,因为当集群的处理能力降低时,P99 延迟会出现显著波动。
此处,固定值或比例的设置方式均可满足实验需求。
具体服务
参数的改,覆盖 NginxMemcachedMongoDB ,具是根据其类型、
围生数空高可,迭
GOMAXPROCS,是 Golang 运行时环境的一个环境变量,来控制可以并发运行
的线理配务器部分
修改,与第三章中介绍的 EnvPupdater 相匹配。
本研究共进行两部分实验:
第一分是 SLO 6.2.2.2 根据
100ms SLO
面向容器编排平台的自动化调优系统研究
62
100ms SLO
使
SLO。并在资源剩余时,尝试减少资源消耗。
SLO
6.2.2.3 基础探索
者是节省资源,后者是最大化资源利用。
这样容器
的自动化调优系统能够在面临不同负载压力情况时,以满足 SLO 为首要目标,
同时兼顾减少资源消耗、支持更高并发两个目标。
6.2.2.2 资源优化
实验一:低并发度压力情况下的微服务优化
1500
于较低水72 CPU 的初总资足够 SLO由于默认源分满足
SLO
持续
差,则进行一次大小为
的扩容,并更新轮次计数。
5.3 3

>
=
,
0
>

。本
究认一种理想化阶
此基础上,优化参数配置,试图获取更佳的延迟表现。同理,如果这个过程中,
由于参数的良好配置,使得延迟表现得到大幅改善,则可进一步优化资源消耗,
进行一次大小为
的缩容。
6-10 并发度压力实验评估的优化过程
Figure 6-10 Optimization process for experimental evaluation under low concurrency
实验分析
63
pressure
实验结果如图 6-10 所示,在低并发条件下,具有默认公平分配的微服务系
SLO 6-6
B使 36 CPU
50%以上。此外,在优化参数后,观察到资源消耗进一步减少。最终结果表明,
SLO 52
CPU,占到总资源的 72%以上。
实验二:高并发度压力情况下的微服务优化
4000
于较支持的服源显够充定的 SLO 72
CPU 的支持下难以实现,P99 延迟达到 1000ms 以上。本研究同样进行实验,
尝试提高性能表现,尽可能靠近 SLO。值得注意的是,本次实验当中,在原
不足的情分配,找
显更优的配置组合,满足 SLO 的情况下,甚至完成了资源消耗的优化。
6-11 并发度压力实验评估的优化过程
Figure 6-11 Optimization process for experimental evaluation under hige concurrency
pressure
6-11 平资源分 SLO然后,本研究进行
了资源分配优化和参数调整,从而减少了延迟。随后,在满足延迟 SLO 后减少
了资(图 6-7 A。在源减之后迟略增加满足 SLO
后实现最佳参数配置和资源分配。最终结果表明,本系统在满足 SLO 的同时,
节省了 27 CPU,占到总资源的 37.5%以上。
从以线化场
的作用。首先,在线资源和参数调整可以在满足 SLO实验一)的同时节省
量资在线可以整个
面向容器编排平台的自动化调优系统研究
64
否可以实 SLO验二并不定每力和源供关系
中都能实现,但本系统能够尝试将整个系统的表现改善。
6.2.2.3 并发优化
本研,用
定的,要在该并发程度下,探索更佳的配置,保持延迟满足 SLO 的前提下,减
少资源消耗。
第二仅是
外尝用户场景,无
用途的时候,也是一个现实的需求。
前半过优
5.3 3

>
=
,
0
>

微服务,研究逐步加每测试的并度, 1000rps 为递增幅,同时进
行参数调优,直到获得一个仍然能够保持 SLO 的最高并发值,最为当前系统的
最大并发能力。实验结果如表 6-8 所示。
6-8 并发优化实验结果
Table 6-8 The results of concurrent optimization experiments
并发度
rps
调优前
调优后
平均延迟
ms
P99 延迟
ms
平均延迟
ms
P99 延迟
ms
1000
5.39
21.22
4.8
19.42
2000
5.83
23.1
5.66
22.82
3000
3980
7180
5.95
24.01
4000
8450
13110
6.6
26.7
5000
10770
16360
8.49
34.59
6000
12480
19610
9.51
39.33
,微服务系统 2000rps 表现处于
低水平。发达大约 3000 rps 时,微服统已法正响应。此
该系统的 P99 迟达到 7 ,严重超出实际业务可接受的范围。然而,经过调
优,即使 6000 rps 的并发级下,系统然能够正此时P99
迟减少到 39.33ms,符合 SLO 要求。因此,与公平分配的默认策略以及应用
序和环境变量的默认配置相比,本优化系统在保持 SLO 的情况下,使得微服务
实验分析
65
系统能够支持更多用户并发。
在此请求
统延迟表现情况绘制成曲线图,如图 6-126-13 所示。
6-12 优前延迟随并发程度增加的变化曲线
Figure 6-12 Curve of latency before tuning as concurrency increases
6-13 优后延迟随并发程度增加的变化曲线
Figure 6-13 Curve of latency after tuning as concurrency increases
6-12 P99 线
6-13 表示调优后 P99 延迟和平均延迟的变化曲线。
如图所示,能观察调优后 P99 延迟和平均延随并度升高而升高
的曲线调优例如况随
面向容器编排平台的自动化调优系统研究
66
请求并发提高每秒请求 1000 上升 6000生剧烈变平均
迟从 10 的数量级(5.39ms)到超 10000 的四个数量级(12480ms不等,类
似地P99 延迟 21.22ms 19610ms反映微服统无
法支持并发度的大幅提高。当并发度超出系统能处理的范围(约 2000 rps 以上)
的时候,出现系统崩溃情况,导致延迟陡增,无法满足用户设定的 SLO
1000
6000总体显示小幅增加平均 4.8ms
幅上 9.51msP99 延迟 19.42ms 39.33ms这反
的微服务系统,有着更合理的资源分配与参数配置,可以稳定承担高并发压力。
OSDI 2023CCF A Cilantro
[22]
Github 中给的实数据对比该工同样 Kubernetes 为代表的
器编进行主要优化
构建映射索策资源
况。相比够基同优
分配和参数配置。
6-9 研究与 Cilantro 作实验对
Table 6-9 Comparison between this study and Cilantro
并发度
rps
资源占用
平均延迟
ms
P99 延迟
ms
Cilantro
3000
152 CPU
64.206
100.934
本研究
3000
72 CPU
5.95
24.01
实验 6-9 研究
3000rps 这一并发级别适中的非极端的请求状态下,支持相同的用户并发请求,
使
Cliantro 47.37% P99
Cilantro 工作效果的 23.79%,平均延迟更是仅有 Cilantro 工作效果的 9.27%
基于统的
系统能够以满足 SLO 为首要目标,同时兼顾减少资源消耗、支持更高并发两个
目标。
6.3 本章小结
本章介绍向容排平台群自化调系统基于 Kubernetes
器编单一进行,包
环境。实体介服务
实验分析
67
线-线-资源
的有程序明,源配
况下配置使表现是资
充足化效显。用, NginxMemcachedRedis
Postgresql,通参数优化,性提升可达 46.55% 208.20%。微务调
部分体包别为优化
资源:资情况资源
和收 SLO 要求 52 CPU源的 72%
上;高并参数收缩
SLO 27 CPU 37.5%
40ms
请求数,到优前的三倍上, OSDI 2023 工作 Cilantro 相比,本
究可使系统况下相同
程度,优化效果显著。
面向容器编排平台的自动化调优系统研究
68
7
总结与展望
本章存在
行归纳和展望,为未来研究指明方向。
7.1 工作总结
本文序资
合理研究器编调优
实现用的的优能,使
服务系统在满足用户 SLO 的前提下实现资源的节省以及并发度的提高。其中,
具体工作内容包括:
1. 动化
容器排平 Kubernetes 机制度定
模块
个调优系统的运行逻辑,同时作为控制中心与其他三个模块进行交互。
的形
源管
略更
或根
四个模块协同工作,实现自动化调优。
2. 研究离线-线结识别方法主要两部:基成学
线在线
通过 CART 策树森林载识,进知识的构
LASSO
斯过
在负
行准
差的
使得
在四
估结表明文提的离线-线结合的优化能够应用
参数
应用性能。
3. 研究资源-数联优方资源降算主要为两,实
源下
总结与展望
69
及通
评估策略得分,更高效搜索分配空间。后者是通过多层次优化的逻辑,
DeathStarBench
[40]
HotelReservation 的基准测试上的实验评估结果表明,本文提出的
- SLO
用和
集群整体资源消耗,同时提高集群并发处理能力。
7.2 未来工作展望
本文设计并实现的面向容器编排平台的集群自动化调优系统分别从离线-
线结合的识别优化方法和资-参数联合调优方法及资源下降算法两个方面进行
研究群中数配应用
并使微服务系统在满足用户 SLO 的前提下,实现资源的节省以及并发度的提高。
然而在一续研归纳
几个方面:
1.本研究关于参数配置调优的工作中,参数空间的构建,仍需依赖人工
成。本应的变的取
选取数的工核过构线
知识成准成的使,但
与意程度计的衷不
来的研究工作中,应当尝试探索自动化构建参数空间的方法与范式。
2.本研究关于资源分配和参数配置联合调优的工作中,采用多层次优化
逻辑联合定挑化意
化的解耦,因此,需要更近一步探索不同的优化层次的优化终点的一致性情况,
避免点不或无高自
优系统的有效性。
3.本研究关于微服务场景的优化工作,使用学术界认可的开源的微服务
准测 DeathStarBench
和资素影实际可能
异。工作自动和稳
将代码开源和真实环境的落地应用作为工作重点。
面向容器编排平台的自动化调优系统研究
70
参考文献
[1] Burns B, Grant B, Oppenheimer D, et al. Borg, omega, and kubernetes[J].
Communications of the ACM, 2016, 59(5): 50-57.
[2] Hindman B, Konwinski A, Zaharia M, et al. Mesos: A platform for {Fine-
Grained} resource sharing in the data center[C]//8th USENIX Symposium on
Networked Systems Design and Implementation (NSDI 11). 2011.
[3] Dimakopoulos V .Spark on Hadoop YARN & Kubernetes for Scalable Physics
Analysis In collaboration with CERN Openlab, Intel, CMS Experiment,
Fermilab[J]. 2018.
[4] Cloud Native Computing Foundation. https://www.cncf.io/
[5] Kubernetes adoption, security, and market trends report 2023.
https://www.redhat.com/en/resources/kubernetes-adoption-security-market-
trends-overview
[6] Li C, Wang S, Hoffmann H, et al. Statically inferring performance properties of
software configurations[C]//Proceedings of the Fifteenth European Conference
on Computer Systems. 2020: 1-16.
[7] Huang H, Zhao Y, Rao J, et al. Adapt burstable containers to variable CPU
resources[J]. IEEE Transactions on Computers, 2022, 72(3): 614-626.
[8] Nginx[J].Programmer, 2007.
[9] White T. Hadoop: The definitive guide[M]. " O'Reilly Media, Inc.", 2012.
[10] Spark A. A Unified Engine for Big Data Processing[J]. Commun. ACM, 2016,
59(11): 56-65.
[11] Zhu Y, Liu J, Guo M, et al. Bestconfig: tapping the performance potential of
systems via automatic configuration tuning[C]//Proceedings of the 2017
symposium on cloud computing. 2017: 338-350.
[12] Christian Dupuis.Professional Apache Tomcat 6[J]. 2007.
[13] Jiang C, Wu P. A Fine-Grained Horizontal Scaling Method for Container-Based
Cloud[J]. Scientific Programming, 2021, 2021: 1-10.
[14] Kannan R S, Subramanian L, Raju A, et al. Grandslam: Guaranteeing slas for
jobs in microservices execution frameworks[C]//Proceedings of the Fourteenth
EuroSys Conference 2019. 2019: 1-16.
[15] Qiu H, Banerjee S S, Jha S, et al. {FIRM}: An intelligent fine-grained resource
management framework for {SLO-Oriented} microservices[C]//14th USENIX
symposium on operating systems design and implementation (OSDI 20). 2020:
805-825.
[16] Kim E, Lee K, Yoo C. Network SLO-aware container scheduling in
Kubernetes[J]. The Journal of Supercomputing, 2023, 79(10): 11478-11494.
参考文献
71
[17] Kaur K, Garg S, Kaddoum G, et al. KEIDS: Kubernetes-based energy and
interference driven scheduler for industrial IoT in edge-cloud ecosystem[J]. IEEE
Internet of Things Journal, 2019, 7(5): 4228-4237.
[18] Han R, Liu C H, Zong Z, et al. Workload-adaptive configuration tuning for
hierarchical cloud schedulers[J]. IEEE Transactions on Parallel and Distributed
Systems, 2019, 30(12): 2879-2895.
[19] Beltre A, Saha P, Govindaraju M. Kubesphere: An approach to multi-tenant fair
scheduling for kubernetes clusters[C]//2019 IEEE cloud summit. IEEE, 2019: 14-
20.
[20] Kash I A, O'Shea G, Volos S. DC-DRF: Adaptive multi-resource sharing at
public cloud scale[C]//Proceedings of the ACM symposium on cloud computing.
2018: 374-385.
[21] Lin M, Xi J, Bai W, et al. Ant colony algorithm for multi-objective optimization
of container-based microservice scheduling in cloud[J]. IEEE access, 2019, 7:
83088-83100.
[22] Bhardwaj R, Kandasamy K, Biswal A, et al. Cilantro:{Performance-Aware}
resource allocation for general objectives via online feedback[C]//17th USENIX
Symposium on Operating Systems Design and Implementation (OSDI 23). 2023:
623-643.
[23] Chow K H, Deshpande U, Seshadri S, et al. DeepRest: deep resource estimation
for interactive microservices[C]//Proceedings of the Seventeenth European
Conference on Computer Systems. 2022: 181-198.
[24] Bao Y, Peng Y, Wu C. Deep learning-based job placement in distributed machine
learning clusters[C]//IEEE INFOCOM 2019-IEEE conference on computer
communications. IEEE, 2019: 505-513.
[25] Peng Y, Bao Y, Chen Y, et al. Dl2: A deep learning-driven scheduler for deep
learning clusters[J]. IEEE Transactions on Parallel and Distributed Systems, 2021,
32(8): 1947-1960.
[26] Zhang J, Liu Y, Zhou K, et al. An end-to-end automatic cloud database tuning
system using deep reinforcement learning[C]//Proceedings of the 2019
international conference on management of data. 2019: 415-432.
[27] Zhang J, Zhou K, Li G, et al. CDBTune+: An efficient deep reinforcement
learning-based automatic cloud database tuning system[J]. The VLDB Journal,
2021, 30(6): 959-987.
[28] Li G, Zhou X, Li S, et al. Qtune: A query-aware database tuning system with
deep reinforcement learning[J]. Proceedings of the VLDB Endowment, 2019,
12(12): 2118-2130.
[29] Van Aken D, Pavlo A, Gordon G J, et al. Automatic database management
system tuning through large-scale machine learning[C]//Proceedings of the 2017
ACM international conference on management of data. 2017: 1009-1024.
面向容器编排平台的自动化调优系统研究
72
[30] Gao Z, Wang T, Wang Q, et al. Execution Time Prediction for Apache
Spark[C]//Proceedings of the 2018 International Conference on Computing and
Big Data. 2018: 47-51.
[31] Rahman M A, Hossen J, Sultana A, et al. A smart method for spark using neural
network for big data[J]. International Journal of Electrical and Computer
Engineering, 2021, 11(3): 2525.
[32] go.sum · openEuler https://gitee.com/openeuler/A-Tune/ blob/master/go.sum.
[33] Acher M, Martin H, Pereira J A, et al. Learning very large configuration spaces:
What matters for Linux kernel sizes[D]. Inria Rennes-Bretagne Atlantique, 2019.
[34] Acher M, Martin H, Pereira J A, et al. Learning from thousands of build failures
of Linux kernel configurations[D]. Inria; IRISA, 2019.
[35] Martin H, Acher M, Pereira J A, et al. Transfer learning across variants and
versions: The case of linux kernel size[J]. IEEE Transactions on Software
Engineering, 2021, 48(11): 4274-4290.
[36] Yi L, Connan J. KernTune: self-tuning Linux kernel performance using support
vector machines[C]//Proceedings of the 2007 annual research conference of the
South African institute of computer scientists and information technologists on IT
research in developing countries. 2007: 189-196.
[37] Curioso A, Bradford R, Galbraith P. Expert PHP and MySQL[M]. John Wiley &
Sons, 2010.
[38] , . Redis [J]. , 2013,
32(12): 11-13.
[39] Geschwinde E, Schönig H J. PostgreSQL developer's handbook[M]. Sams
Publishing, 2002.
[40] Gan Y, Zhang Y, Cheng D, et al. An open-source benchmark suite for
microservices and their hardware-software implications for cloud & edge
systems[C]//Proceedings of the Twenty-Fourth International Conference on
Architectural Support for Programming Languages and Operating Systems. 2019:
3-18.
[41] Rodríguez-Haro F, Freitag F, Navarro L, et al. A summary of virtualization
techniques[J]. Procedia Technology, 2012, 3: 267-272.
[42] Eder M. Hypervisor-vs. container-based virtualization[J]. Future Internet (FI) and
Innovative Internet Technologies and Mobile Communications (IITM), 2016, 1.
[43] Morabito R, Kjällman J, Komu M. Hypervisors vs. lightweight virtualization: a
performance comparison[C]//2015 IEEE International Conference on Cloud
Engineering. IEEE, 2015: 386-393.
[44] Noronha V, Lang E, Riegel M, et al. Performance evaluation of container based
virtualization on embedded microprocessors[C]//2018 30th International
Teletraffic Congress (ITC 30). IEEE, 2018, 1: 79-84.
参考文献
73
[45] Soltesz S, Pötzl H, Fiuczynski M E, et al. Container-based operating system
virtualization: a scalable, high-performance alternative to
hypervisors[C]//Proceedings of the 2Nd ACM SIGOPS/EuroSys european
conference on computer systems 2007. 2007: 275-287.
[46] Potdar A M, Narayan D G, Kengond S, et al. Performance evaluation of docker
container and virtual machine[J]. Procedia Computer Science, 2020, 171: 1419-
1428.
[47] Rad B B, Bhatti H J, Ahmadi M. An introduction to docker and analysis of its
perfor mance[J]. International Journal of Computer Science and Network
Security (IJCSNS), 2017, 17(3): 228.
[48] 佟旭.基于 Docker Swarm 集群的资源亲和性调度算法[D].兰州大学,2018.
[49] Kwon S, Lee J H. Divds: Docker image vulnerability diagnostic system[J]. IEEE
Access, 2020, 8: 42666-42673.
[50] Combe T, Martin A, Di Pietro R. To docker or not to docker: A security
perspective[J]. IEEE Cloud Computing, 2016, 3(5): 54-62.
[51] .Docker [J].,2017,34(07):62
66.DOI:10.19339/j.issn.1674-2583.2017.07.014.
[52] Medel V, Rana O, Bañares J Á, et al. Modelling performance & resource
management in ku bernetes[C]//Proceedings of the 9th International Conference
on Utility and Cloud Compu ting. 2016: 257-262.
[53] Sahu N, Thakre S C. A survey on Kubernetes architec-ture and its
significance[R]. EasyChair, 2022.
[54] Kayal P. Kubernetes in Fog Computing: Feasibility Demonstration, Limitations
and Improve ment Scope[C]//2020 IEEE 6th World Forum on Internet of Things
(WF-IoT). IEEE, 2020: 16.
[55] . Kubernetes [D].
,2021.DOI:10.26969/d.cnki.gbydu.2021.002291.
[56] ,梓群,恪振,隆勇.Kubernetes 资源动态调度设计[J].
导刊,2022,21(02):109-114.
[57] , . Kubernetes CI/CD [J].
,2020,29(12):268 271.DOI:10.15888/j.cnki.csa.007682.
[58] Ongaro D, Ousterhout J. In search of an understandable consensus
algorithm[C]//2014 USE NIX Annual Technical Conference (Usenix ATC 14).
2014: 305-319.
[59] Han S, Lee S. Persistent store-based dual replication system for distributed SDN
control ler[C]//2016 International Conference on Selected Topics in Mobile &
Wireless Networking (MoWNeT). IEEE, 2016: 1-2.
[60] Telenyk S, Sopov O, Zharikov E, et al. A Comparison of Kubernetes and
Kubernetes-Com patible Platforms[C]//2021 11th IEEE International Conference
面向容器编排平台的自动化调优系统研究
74
on Intelligent Data Acquisi tion and Advanced Computing Systems: Technology
and Applications (IDAACS). IEEE, 2021, 1: 313-317.
[61] Fazio M, Celesti A, Ranjan R, et al. Open issues in scheduling microservices in
the cloud[J]. IEEE Cloud Computing, 2016, 3(5): 81-88.
[62] GitHub - brianfrankcooper/YCSB: Yahoo! Cloud Serving Benchmark
github.com. https://github.com/ brianfrankcooper/YCSB.
[63] Kato T, Uemura M. Period analysis using the least absolute shrinkage and
selection operator (Lasso)[J]. Publications of the Astronomical Society of Japan,
2012, 64(6): 122.
[64] Brunelle J F, Nelson M L, Balakireva L, et al. Evaluating the SiteStory
transactional web archive with the ApacheBench tool[C]//Research and
Advanced Technology for Digital Libraries: International Conference on Theory
and Practice of Digital Libraries, TPDL 2013, Valletta, Malta, September 22-26,
2013. Proceedings 3. Springer Berlin Heidelberg, 2013: 204-215.
[65] Ahmed M, Uddin M M, Azad M S, et al. MySQL performance analysis on a
limited resource server: Fedora vs. Ubuntu Linux[C]//Proceedings of the 2010
Spring Simulation Multiconference. 2010: 1-7.
[66] Abadi D J. Data management in the cloud: Limitations and opportunities[J].
IEEE Data Eng. Bull., 2009, 32(1): 3-12.
[67] GitHub- giltene/wrk2: A constant throughput, cor rect latency recording variant
of wrk github.com. https://github.com/giltene/wrk2.
[68] 5th Generation Intel® Xeon® Scalable Processors.
https://edc.intel.com/content/www/us/en/products/performance/benchmarks/5th-
generation-intel-xeon-scalable-processors/
[69] 李启,彭志,崔得,.容器环境拟资置策略的[J].
机应用, 2019, 39(03): 784-789.
[70] 陈国良,王熙法,庄镇泉等.遗传算法及其应用[M].人民邮电出版社, 1999.
[71] ,,.改进蛙跳流负[J].
计算机科学, 2019, 46(11): 315-322.
[72] 杨维,李歧强.粒子群优化算法综述[J].中国工程科学, 6(5): 87-94.
[73] Chandrasekaran K , Joseph C T . IntMA: Dynamic Interaction-Aware Resource
Allocation for Containerized Microservices in Cloud environments[J]. Journal of
Systems Architecture, 2020, 111:101785.
[74] Yang Y , Dusia A . Network Quality of Service in Docker Containers[C]// IEEE
International Conference on Cluster Computing. IEEE, 2015.
[75] McDaniel S, Herbein S, Taufer M. A two-tiered approach to I/O quality of
service in docker containers[C]//2015 IEEE International Conference on Cluster
Computing. IEEE, 2015: 490-491.
参考文献
75
[76] Fekry A, Carata L, Pasquier T, et al. Tuneful: An online significance-aware
configuration tuner for big data analytics[J]. arXiv preprint arXiv:2001.08002,
2020.
[77] Öztürk M M. Tuning parameters of Apache Spark with Gauss–Pareto-based
multi-objective optimization[J]. Knowledge and Information Systems, 2024,
66(2): 1065-1090.
[78] Goettel B C. CadVisor (CAD Equipment Analysis and Selection
System)[C]//Computing in Civil Engineering. ASCE, 1994: 2140-2144.
[79] Timofeev R. Classification and regression trees (CART) theory and
applications[J]. Humboldt University, Berlin, 2004, 54.
[80] Safavian S R, Landgrebe D. A survey of decision tree classifier methodology[J].
IEEE transactions on systems, man, and cybernetics, 1991, 21(3): 660-674.
[81] Blockeel H, Struyf J. Efficient algorithms for decision tree cross-validation[J].
Journal of Machine Learning Research, 2002, 3(Dec): 621-650.
[82] Bratley P, Fox B L, Niederreiter H. Implementation and tests of low-discrepancy
sequences[J]. ACM Transactions on Modeling and Computer Simulation
(TOMACS), 1992, 2(3): 195-213.
[83] Banerjee A, Dunson D B, Tokdar S T. Efficient Gaussian process regression for
large datasets[J]. Biometrika, 2013, 100(1): 75-89.
[84] Frazier P I. A tutorial on Bayesian optimization[J]. arXiv preprint
arXiv:1807.02811, 2018.
[85] Zhang Y, Wang S, Ji G. A comprehensive survey on particle swarm optimization
algorithm and its applications[J]. Mathematical problems in engineering, 2015,
2015.
[86] memtier_benchmark: A High-Throughput Benchmarking Tool for Redis &
Memcached.https://redis.com/blog/memtier_benchmark-a-high-throughput-
benchmarking-tool-for-redis-memcached/
[87] Aderaldo C M, Mendonça N C, Pahl C, et al. Benchmark requirements for
microservices architecture research[C]//2017 IEEE/ACM 1st International
Workshop on Establishing the Community-Wide Infrastructure for Architecture-
Based Software Engineering (ECASE). IEEE, 2017: 8-13.
[88] Yu Z, Bei Z, Qian X. Datasize-aware high dimensional configurations auto-
tuning of in-memory cluster computing[C]//Proceedings of the Twenty-Third
International Conference on Architectural Support for Programming Languages
and Operating Systems. 2018: 564-577.
[89] Wang G, Xu J, He B. A novel method for tuning configuration parameters of
spark based on machine learning[C]//2016 IEEE 18th International Conference
on High Performance Computing and Communications; IEEE 14th International
Conference on Smart City; IEEE 2nd International Conference on Data Science
and Systems (HPCC/SmartCity/DSS). IEEE, 2016: 586-593.
面向容器编排平台的自动化调优系统研究
76
附录一 Task 示例
77
附录一
Task
示例
1. apiVersion: k8stune.k8stune/v1
2. kind: Task
3. metadata:
4. labels:
5. app.kubernetes.io/name: task
6. app.kubernetes.io/instance: task-sample
7. app.kubernetes.io/part-of: k8stune
8. app.kubernetes.io/managed-by: kustomize
9. app.kubernetes.io/created-by: k8stune
10. name: nginx-online-task
11. namespace: paperexp
12. spec:
13. TaskConfig:
14. object: # 需要调优对象的列表,此处仅有使用 deployment 部署的 Nginx
15. type: deployment
16. namespace: default
17. name: nginx
18. taskType: online # 在线参数调优
19. taskPolicy: default #
不使用离线知识库
20. onlineCycle: "30s" # 每轮次观测的间隔时长
21. parameters:
22. - agentInfo:
23. filePath: /etc/nginx/nginx.conf #
配置文件路径
24. name: "nginx-controlagent" # Agent 名称
25. namespace: "nginx" # Agent
命名空间
26. updater: "K8sAppandRuntimePupdater" # 使用的 Pupdater
27. paramterSet: #
需要修改的参数
28. - name: "nginx.access_log"
29. - name: "nginx.multi_accept"
30. ……
31. - name: "nginx.worker_processes"
32. - name: "nginx.worker_connections"
33. metrics: #
基准测试或观测信息
34. - agent:
35. name: "nginx-collectagent" # collectagent
的名称和命名空间
36. namespace: "nginx"
37. benchPerformance: #
作为反馈的指标
38. - name: "rps"
面向容器编排平台的自动化调优系统研究
78
附录二
ControlAgent
示例
1. apiVersion: k8stune.k8stune/v1
2. kind: ControlAgent
3. metadata:
4. name: nginx-controlagent #名字和命名空间
5. namespace: paperexp
6. spec:
7. agentInfo:
8. filePath: /etc/nginx/nginx.conf #修改参数的文件
9. name: nginx-controlagent
10. updater: K8sAppandRuntimePupdater
11. parameterSet: #
可修改参数
12. - desc: Enabling or Disabling nginx access
13. dtype: string #
类型
14. # 获取参数的值的方式 %s 是参数名称
15. get: grep -m1 'access_log' %s | awk -F ' ' '{print $2}'
16. name: nginx.access_log # 参数名称
17. options: #string
类型的具体选项
18. - /var/log/nginx/access.log main
19. - "off"
20. #修改参数的方式,两处 %s 分别是参数名称和值
21. set: sed -i 's#access_log .*#access_log %s;#g' %s
22. - desc: Enabling or Disabling nginx error_log
23. dtype: string
24. get: grep -m1 'error_log' %s | awk -F ' ' '{print $2}'
25. name: nginx.error_log
26. options:
27. - /var/log/nginx/error.log
28. - /dev/null
29. set: sed -i 's#error_log .*#error_log %s;#g' %s
30. - dataRange:
31. lower: "1"
32. upper: "5"
33. desc: work process
34. dtype: int
35. get: grep -m1 'worker_processes' %s | awk -F ' ' '{print $2}'
36. name: nginx.worker_processes
37. set: sed -i 's#worker_processes .*#worker_processes %s;#g' %s
38. - dataRange:
39. lower: "256"
40. upper: "2048"
41. desc: connection
42. dtype: int
43. get: grep -m1 'worker_connections' %s | awk -F ' ' '{print $2}'
44. name: nginx.worker_connections
45. set: sed -i 's#worker_connections .*#worker_connections %s;#g' %s
46. - dataRange: #float int 类型参数进行取值范围的限定
47. lower: "1"
48. upper: "9"
49. desc: gzip_comp_level
50. dtype: int
51. get: grep -m1 'gzip_comp_level' %s | awk -F ' ' '{print $2}'
52. name: nginx.gzip_comp_level
53. set: sed -i 's#gzip_comp_level .*#gzip_comp_level %s;#g' %s
54. - desc: multi_accept
55. dtype: string
56. get: grep -m1 'multi_accept' %s | awk -F ' ' '{print $2}'
57. name: nginx.multi_accept
58. options:
59. - "on"
附录二 ControlAgent 示例
79
60. - "off"
61. set: sed -i 's#multi_accept .*#multi_accept %s;#g' %s
62. - desc: proxy_buffers
63. dtype: string
64. get: grep -m1 'proxy_buffers' %s | awk -F ' ' '{print $2}'
65. name: nginx.proxy_buffers
66. options:
67. - 4 4k
68. - 6 4k
69. - 6 8k
70. - 4 8k
71. set: sed -i 's#proxy_buffers .*#proxy_buffers %s;#g' %s
72. - desc: proxy_busy_buffers_size
73. dtype: string
74. get: grep -m1 'proxy_busy_buffers_size' %s | awk -F ' ' '{print $2}'
75. name: nginx.proxy_busy_buffers_size
76. options:
77. - 8k
78. - 12k
79. set: sed -i 's#proxy_busy_buffers_size .*#proxy_busy_buffers_size %s;#g' %s
80. - desc: sendfile
81. dtype: string
82. get: grep -m1 'sendfile' %s | awk -F ' ' '{print $2}'
83. name: nginx.sendfile
84. options:
85. - "on"
86. - "off"
87. set: sed -i 's#sendfile .*#sendfile %s;#g' %s
88. - desc: tcp_nopush
89. dtype: string
90. get: grep -m1 'tcp_nopush' %s | awk -F ' ' '{print $2}'
91. name: nginx.tcp_nopush
92. options:
93. - "on"
94. - "off"
95. set: sed -i 's#tcp_nopush .*#tcp_nopush %s;#g' %s
96. - dataRange:
97. lower: "0"
98. upper: "4096"
99. desc: gzip_min_length
100. dtype: int
101. get: grep -m1 'gzip_min_length' %s | awk -F ' ' '{print $2}'
102. name: nginx.gzip_min_length
103. set: sed -i 's#gzip_min_length .*#gzip_min_length %s;#g' %s
104. - desc: gzip
105. dtype: string
106. get: grep -m1 'gzip' %s | awk -F ' ' '{print $2}'
107. name: nginx.gzip
108. options:
109. - "on"
110. - "off"
111. set: sed -i 's#gzip .*#gzip %s;#g' %s
112. - desc: gzip_buffers
113. dtype: string
114. get: grep -m1 'gzip_buffers' %s | awk -F ' ' '{print $2}'
115. name: nginx.gzip_buffers
116. options:
117. - 4 32k
118. - 8 64k
119. - 8 32k
120. - 16 64k
121. - 16 32k
122. - 2 16k
123. set: sed -i 's#gzip_buffers .*#gzip_buffers %s;#g' %s
面向容器编排平台的自动化调优系统研究
80
在我所有
深深里的容,鼓励
与支段旅这些使坚持
并最终为人生的这一阶段画上句号。
首先军老
知识让我术造为我
榜样两位能软激起
研的走进殿中,了良
研环扫平。两了很沿
的专们强使命感一直
习的榜样。
其次期间
和无整个师既,更
的朋到困,提。感
软件吴敬于佳在我
道路持与、丁师、
老师对研究生日常事务的耐心解答。
我还包括皓师
何家承杰,感论学
时给了我一些启发。
此外们对
条件护,谢我的理
励和困难。他学之
强后盾。
最后谢那
以任和支里未铭记
并以我的成就来回报他们的帮助和鼓励。
我深是不
这份致谢送给所有在这段旅程中与我同行的人。
致谢
81
面向容器编排平台的自动化调优系统研究
82
作者简历及攻读学位期间发表的学术论文与其他相关学术成
作者简历:
2017 9 ——2021 7 月,在南开大学计算机学院获得学士学位。
2021 9 ——2024 7 月,在中国科学院大学软件研究所攻读硕士学位。
已发表(或正式接受)的学术论文:
申请或已获得的专利:
1元,家泰佳耕. 一种习的
Linux 系统内核配置的策略推荐方法及装置. 申请号:CN202310909401.
2元,山云开创于佳.
.
CN202310792705.
3元,. 种基场和样本法及
装置. 申请号:CN202310960660.
参加的研究项目及获奖情况:
1)参与 123 项目 1-1
2 RISC-V
(2023YFB4503900)” 子课题 5-2 “RISC-V 性能与稳定性的研究与评估
3
V1.0. 登记号:2023SR0481878
42021 年中国科学院大学硕士生二等学业奖学金
52022 年中国科学院大学硕士生三等学业奖学金
62023 年中国科学院大学硕士生二等学业奖学金